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a  viable  technology  that  is  applicable  in  a  LAN  environment.  However,  migrating  from 
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This  study  reviews  ATM  technology  and  its  application  in  a  LAN  environment, 
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L  INTRODUCTION 


A.  BACKGROUND 

Since  the  appearance  of  Local  Area  Networks  (LANs),  their  use  and  bandwidth 
consumption  have  increased  considerably.  As  more  users  access  the  LANs,  and  their 
applications  capability  (text,  graphics,  and  video  intensity)  increases,  higher  bandwidth  will 
be  required.  No  longer  is  the  "normal"  10  or  16  megabits  per  second  (Mbps)  pipes  the 
typical  option  when  installing  new  LANs  or  upgrading  existing  ones.  Users  are  now 
asking  for  substantial  increases  in  bandwidth  to  meet  their  application-intensive  bandwidth 
requirements,  and  to  allow  multiple  simultaneous  access  to  the  pipes. 

New  technologies  have  emerged  to  satisfy  this  demand  for  bandwidth.  They 
include  Fast  Ethernet  (100  Mbps),  Fiber  Distributed  Data  Interface  (FDDI),  and 
Asynchronous  Transfer  Mode  (ATM). 

Cost  is  a  major  driving  factor  in  deciding  to  adapt  new  LAN  technology.  User  will 
always  pose  the  question,  how  much  will  it  cost  to  install  the  new  technology?  In  the  case 
of  ATM,  users  are  also  asking  themselves,  do  I  want  to  be  the  first  to  implement  an  ATM 
network,  and  what  are  my  risks? 

ATM  has  made  several  strides,  and  is  now  considered  as  a  viable  technology  that  is 
applicable  in  the  LAN  environment.  Although  ATM  was  originally  developed  as  an 
international  standard  for  Synchronous  Optical  Network  (SONET)-based  Wide  Area 
Networks  (WANs),  its  attractiveness  for  LANs  has  resulted  in  ATM  LANs  appearing  well 
in  advanced  of  long-haul  ATM  services.  The  Army  High-Performance  Computer 
Research  Center  performed  experiments  in  1993  to  evaluate  the  capability  of  ATM 
satisfying  the  communications  needs  of  distributed  networking  computing.  The  results 
revealed  that  network  computing  is  very  promising  over  Local  ATM  Networks. 

B.  PURPOSE 

The  purpose  of  this  thesis  is  to  redesign  the  Systems  Management  (SM) 
Department's  computer  lab  LANs  using  ATM  technology.  The  research  entails  reviewing 
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ATM  technology,  assessing  the  existing  computer  lab  LANs,  redesigning  the  lab  LANs, 
and  devising  a  strategy  to  upgrade  the  current  LANs  to  an  Local  ATM  Network. 

C.  SCOPE  AND  METHODOLOGY 

The  main  focus  of  this  research  is  to  review  ATM  technology  and  its  possible  use 
in  a  LAN  environment;  perform  an  in  depth  study  of  the  existing  SM  Department 
computer  lab  LANs  in  Ingersoll  IN-158,  IN-224,  and  IN-250;  redesign  the  current  lab 
network;  and  the  development  of  an  evolutionary  strategy  to  implement  the  proposed 
ATM  LAN. 

The  research  will  entail  a  review  of  current  books,  periodicals  and  news  articles  on 
LANs,  ATM  technology,  and  Local  ATM  Networks.  Academic  and  professional 
specialists  will  also  be  interviewed.  These  specialists  will  have  been  involved  in  the  de¬ 
velopment  of  LANs  and  WANs,  and  have  an  understanding  of  the  ATM  technology.  My 
emphasis  will  be  on  hardware  and  software  required  to  implement  the  Local  ATM 
Network,  and  the  hardware  and  software  compatibility  issues  that  may  occur  when 
running  existing  applications  on  a  Local  ATM  Network. 

D.  ORGANIZATION  OF  STUDY 

Before  delving  into  converting  an  existing  LAN  to  a  Local  ATM  Network,  one 
should  have  a  clear  understanding  of  ATM,  its  application  in  a  local  environment,  and 
implementation  issues  associated  with  ATM.  Because  these  areas  will  play  a  crucial  part 
in  upgrading  the  SM  computer  lab  LANs,  I  have  devoted  Chapters  11  and  IE  to  these 
topics.  The  remaining  chapters  cover  an  assessment  of  the  SM  lab  LANs,  the  application 
of  ATM  technology  to  the  LANs,  and  a  migration  strategy  to  convert  or  upgrade  the  SM 
lab  LANs  to  an  ATM  LAN.  The  final  chapter  provides  a  conclusion  of  my  research. 
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n.  ASYNCHRONOUS  TRANSFER  MODE  (ATM)  TECHNOLOGY 


A.  INTRODUCTION 

1.  Purpose  of  Chapter 

The  purpose  of  this  chapter  is  to  provide  a  basic  concept  of  ATM.  An  overview  of 
ATM's  functionality  is  given,  and  standardization  issues  are  discussed.  The  information 
presented  in  this  chapter  gives  a  general  understanding  of  ATM.  In-depth  information  can 
be  obtained  in  the  resources  provided  in  the  List  of  References  and  the  Bibliography. 

2.  Evolution  of  ATM 

To  better  understand  the  evolution  of  ATM,  a  brief  look  at  pre-ATM  technologies 
(circuit  switching,  packet  switching,  and  frame  relay)  is  required.  These  technologies  are 
in  use  today.  However,  as  user  requirements  have  increased,  so  has  the  need  to  transfer 
information  in  faster  and  more  efBcient  modes.  New  applications  are  being  implemented 
which  require  higher  bandwidth,  better  quality  of  services,  and  the  new  transfer  mode 
(ATM).  Some  applications  functions  properly  using  older  and  slower  technologies. 

a.  Circuit  Switching 

Circuit  switching  is  a  transfer  technology  that  has  been  used  in  the 
telephone  system  since  the  advent  of  telephones.  The  Plain  Old  Telephone  System 
(POTS)  uses  circuit  switching  technology.  POTS  establishes  a  circuit,  path,  or  connection 
to  set  up  the  call  and  maintains  the  connection  for  the  duration  of  the  call.  However,  both 
parties  must  be  available  at  their  respective  node  to  establish  the  connection.  The  path 
terminates  when  one  of  the  users  breaks  the  connection  by  "hanging  up"  the  receiver. 

Though  circuit  switching  was  originally  designed  for  telephone 
communications,  it  has  found  tremendous  use  in  data  transfer.  Many  users  use  this 
transfer  mode  for  traffic  that  is  time  sensitive,  has  a  constant  bit  rate,  and  regular 
transmission  intervals. 
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Circuit  switching  has  two  primary  advantages.  It  is  transparent,  in  that 
once  the  connection  is  made,  no  additional  processing  is  required  by  the  sending  or 
receiving  units.  The  second  advantage  is  that  during  the  data  transfer  phase,  routing,  flow 
control,  and  error  control  are  avoided.  This  allows  for  simplicity  in  software.  (Stallings, 
W.,  1992,  p.  28) 

A  key  disadvantage  of  circuit  switching  is  the  inefficient  use  of  lines 
(trunks).  Once  the  circuit  is  established,  the  line  is  not  available  for  other  users.  These 
users  receive  a  busy  signal  when  trying  to  access  the  line. 

b.  Packet  Switching 

Packet  switching  transfer  mode  partially  evolved  as  a  result  of  the 
inefficient  use  of  lines  in  circuit  switching.  As  users  discovered  the  advantages  of 
transmitting  information  over  telephone  lines,  data  communications  grew  tremendously. 
The  circuit  switching  technology  alone  could  not  efficiently  meet  the  growing  bandwidth 
demand.  Telecommunications  experts  invented  a  transfer  mode  (packet  switching)  that 
allowed  the  sharing  of  bandwidth  and  included  store  and  forward  schemes  to 
accommodate  congestion  or  busy  signals  between  nodes. 

Packet  switching  uses  a  method  known  as  packetizing  to  disassemble 
messages  into  multiple  packets.  Each  packet  contains  a  header  for  addressing,  and  error 
control.  The  header  information  allows  the  packets  to  take  various  paths  to  reach  their 
destination.  At  the  destination,  the  packets  are  sequenced,  depacketized,  and  the  message 
is  reformatted  to  be  readable  by  the  receiver(s). 

The  disassembly  and  reassembly  of  the  message  requires  more  time.  As  a 
result,  this  transfer  method  is  not  efficient  for  the  transmission  of  time  sensitive 
information  (voice  and  video).  However,  it  does  allow  the  use  of  shared  bandwidth 
(packets  taking  various  path  to  reach  the  destination).  This  makes  packet  switching 
suitable  for  bursty  traffic  such  as  data. 
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c.  Frame  Relay 

Frame  relay  is  a  form  of  fast  packet  switching  and  its  concepts  are  similar 
to  "regular"  packet  switching.  However,  frame  relay  uses  faster  transmission  facilities. 
No  addressing,  flow  control,  or  error  control  is  used.  The  data  is  packetized  into  variable 
sizes.  Before  any  data  is  transmitted,  a  connection  is  established,  a  permanent  virtual 
circuit  is  created,  and  all  the  packets  travel  along  this  one  path  to  the  destination.  There  is 
no  need  for  sequencing  because  the  packets  arrive  at  the  destination  in  the  same  order  that 
they  left  the  origin.  Once  all  the  packets  have  reached  the  destination,  the  circuit  is 
terminated  and  is  available  for  use  by  other  parties. 

d.  ATM 

ATM  (also  called  cell  relay)  is  another  form  of  fast  packet  switching. 
Unlike  other  switching  technologies,  ATM  relay  uses  fixed  sized  packets  instead  of 
variable  sized  packets.  ATM  takes  the  advantages  of  circuit  switching  and  packet 
switching,  and  combines  them  to  maximize  efficiency,  transmission  speed,  and  throughput 
(Luce,  C.  A.,  1994,  p.  26).  Circuit  switching  establishes  permanent  circuits  before  data  is 
transmitted.  ATM  sets  up  virtual  circuits  using  virtual  path  identifiers  and  virtual  channel 
identifiers.  These  circuits  remain  intact  for  the  duration  of  the  connection  and  each  cell 
uses  this  path  to  reach  the  destination.  Similar  to  frame  relay,  where  the  bandwidth  is 
shared,  other  users  can  use  the  virtual  path  when  it  is  idle  and  awmting  a  response  from 
either  the  sender  or  the  receiver  which  established  the  path  originally. 

3.  Driving  Factors  behind  ATM 

ATM  is  an  emerging  technology  as  a  result  of  four  factors  (ATM  Forum,  1994). 
First,  ATM  has  grown  out  of  a  need  for  a  worldwide  standard  to  allow  interoperability  of 
information,  regardless  of  the  "end-system"  or  type  of  information.  It  is  driven  by 
international  consensus  instead  of  one  particular  manufacturer,  or  a  group  of  vendors. 
Second,  ATM  is  a  technology  that  can  be  used  in  a  LAN,  metropolitan  area  network 
(MAN),  backbone  network  (BN),  or  WAN  environment.  As  users  requirements  to  expand 
from  a  LAN  to  a  WAN,  even  globally,  ATM  can  be  used  to  accommodate  the  users' 
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needs,  and  the  users  networking  capabilities  will  not  be  the  bmiting  factors.  Third,  ATM 
supports  various  types  of  information  (voice,  data,  video).  It  is  the  only  standard 
designed  to  support  the  simultaneous  transmission  of  voice,  data,  and  video,  as  shown  in 
Figure  2.1.  Lastly,  ATM  allows  for  the  transmission  of  information  at  various  speeds, 
ranging  from  a  few  Mbps  to  several  gigabits  per  second  (Gbps). 


Figure  2: 1  ATM  System  Architecture  (ATM  Forum,  1994) 


4.  Benefits  of  ATM 

Along  with  the  ability  to  simultaneously  transmit  voice,  data,  and  video,  ATM  has 
several  other  key  benefits  that  makes  it  appealing  to  users.  These  benefits,  discussed 
below,  also  contribute  to  ATMs  capability  and  power. 

a.  Simplification  of  Network  Management 

Because  ATM  can  span  from  a  LAN  to  a  WAN,  it  simplifies  network 
management.  Network  managers  can  be  trained  on  one  set  of  tools  or  technology  to 
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manage  an  ATM  LAN,  MAN,  BN,  or  WAN.  As  a  result  training  time  and  cost  are 
reduced. 


b.  Compatibility  with  Current  Cable  Plant 

ATM  is  not  designed  for  a  specific  type  of  physical  transport.  It  can  be 
transported  over  twisted  pair,  coax,  and  fiber.  This  makes  it  compatible  with  existing 
network  cabling  plant,  thereby  alleviating  the  need  to  replace  existing  cabling  with  ATM 
congruous  cabling.  There  are  some  unresolved  issues  regarding  ATM  use  over  satellites. 
These  issues  pertain  to  the  effect  of  satellite  delays  on  data  and  the  issues  of  congestion 
control  and  error  correction  required  for  reliable  transfer  of  data  (ATM  Forum,  1994). 

c.  Incremental  Migration  Capability 

In  order  to  use  ATM  in  an  existing  network,  one  does  not  have  to  wait 
until  the  entire  network  has  been  upgraded  to  an  ATM  network.  Instead,  one  can  gain  the 
benefits  of  ATM  incrementally  by  upgrading  portions  of  the  network  based  on  new 
application  requirements  and  business  needs. 

d.  Long  Architectural  Lifetime 

ATM  is  designed  to  be  flexible  and  scaleable  in  geographic  distance,  the 
number  of  users,  and  access  and  trunk  bandwidths.  ATM  can  be  used  locally,  in  a 
metropolitan  area,  transcontinentally,  or  even  globally.  The  maximum  number  of  ATM 
user  addresses  far  exceeds  FDDI's  (500  for  one  ring,  1,000  for  both  rings).  As  mentioned 
earlier,  ATM  speeds  are  flexible.  They  can  range  from  a  few  Mbps  to  several  Gbps. 

B.  ATM  PRINCIPLES 

This  section  provides  a  general  overview  of  ATM  and  how  it  works. 

1.  ATM  Cell 

As  mentioned  in  the  previous  section,  ATM  uses  fixed  length  cells.  Figure  2.2 
depicts  a  generic  view  of  the  cell  format;  each  cell  contain  53  bytes;  the  first  five  bytes 
consist  of  header  information,  and  the  remaining  48  bytes  is  data.  The  primary  function  of 
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the  header  is  to  act  as  the  addressing  mechanism.  The  data  field  holds  the  actual 
information. 


Header 

Data 

5  Bytes 

48  Bytes 

Figure  2.2  ATM  Cell  Format 


Figure  2.3  provides  a  detail  format  of  the  ATM  cell.  The  header  section  comprises 
of  GFC,  VPI,  VCI,  PTI,  CLP,  and  HEC.  The  VPI,  VCI,  CLP,  and  HEC  will  be  discussed 
in  depth  later.  The  GFC  is  used  for  user  network  interface  (UNI),  workstation- 
to-ATM-switch  connections.  The  GFC  does  not  exist  in  network-network  interface 
(NNI),  ATM-switch-to-ATM-switch  connections.  A  larger  VPI  field  is  used  for  trunking 
in  NNI  connections. 


A 


5  Bytes 

▼ 

A 

48  Bytes 

? 


1  Byte 


GFCA^PI 

VPI 

VPI 

VCI 

PTI 

CLP 

HEC 

CeU 

Payload 

GFC  -  Generic  Flow  Control 
VPI  -  Virtual  Path  Identifier 
VCI  -  Wtual  Channel  Identifier 
PTI  -  Payload  Type  Identifier 
CLP  -  Cell  Loss  Priority 
HEC  -  Header  Error  Control 


Figure  2.3  Detail  ATM  Cell  Format 
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2.  ATM  and  the  Open  System  Interconnection  (OSI)  Model 

The  OSI  model  is  used  with  tremendous  success  to  model  communication  systems. 
The  same  logical  hierarchical  architecture  used  in  OSI  is  used  for  the  ATM  Broadband 
Integrated  Service  Data  Network  (B-ISDN)  network  (de  Prycker,  M.,  1993,  p.  111). 
Figure  2.4  shows  the  ATM  hierarchy  and  the  OSI  model  (Luce,  C.  A.,  1994,  p.  30).  The 
ATM  physical  layer  is  similar  to  the  physical  layer  of  the  OSI  model.  The  ATM  layer  can 
be  considered  as  equivalent  to  the  data  link  layer  of  the  OSI  model.  The  ATM  adaptation 
layer  also  performs  functions  of  both  the  data  link  layer;  it  is  capable  of  performing  a  few 
functions  of  the  presentation,  session,  transport,  and  the  network  layers.  Figure  2.5,  on 
the  following  page,  illustrates  ATM  in  a  layered  architectured  fashion,  and  provides  a 
general  depiction  of  how  ATM  works.  Subsections  3,  4,  and  5  discuss  the  Physical  Layer, 
the  ATM  Layer,  and  the  ATM  Adaptation  Layer. 


ATM  B-ISDN  Protocol  Layers 

OSI  ISO  Reference  Model 

Application  Layer 

Application  Layer 

Higher  Layer 

Presentation, 

Session, 

ATM  Adaption  Layer  (AAL) 
Convergence  Sublayer 

Transport/ 

Network  Layers 

Segmentation  &  Reassembly 
Sublayer 

ATM  Layer 

Data  Link  Layer 

Physical  Layer 

Transmission  Convergence 

Sublayer  and  Physical 

Medium  Dependent 

Sublayer 

Physical  Layer 

Figure  2.4  ATM/B-ISDN  Model  and  OSI  Model 
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Figure  2.5  ATM  Layered  Architecture 
3.  ATM  Physical  Layer 


a.  Sublayers 

The  physical  layer  contains  two  sublayers:  the  Physical  Medium  (PM) 
sublayer  and  the  Transmission  Convergence  (TC)  sublayer.  The  PM  supports  pure 
medium  dependent  bit  functions.  It  is  responsible  for  the  correct  transmission  and 
reception  of  bits  on  the  appropriate  physical  medium.  The  TC  converts  the  ATM  cell 
stream  into  bits  to  be  transported  over  the  physical  medium.  This  sublayer  performs  five 
functions  (de  Prycker,  M.,  1993,  p.  113): 

♦  Cell  rate  decoupling  to  adapt  rate  of  valid  ATM  cells  to  the  payload  capacity  of 
the  system. 

♦  Generation  of  the  HEC  syndrome  of  each  cell  at  the  transmitter,  and  its 
verification  at  the  receiver. 

♦.  Cell  delineation  to  allow  for  recovery  of  cells  at  the  destination. 

♦  Transmission  frame  adaptation. 

♦  Generation  and  recovery  of  transmission  fi-ames. 
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b. 


Error  Control 


ATM  uses  no  link-by-link  error  control.  The  two  end  nodes  on  any 
connection  provide  the  control  at  the  physical  layer  (Luce,  C.  A.,  1994,  p.  31).  The 
header  designates  eight  bits  for  error  detection  and  error  correction.  The  receiver  has  a 
correction  mode  and  a  detection  mode.  In  the  correction  mode,  cells  with  a  single  bit 
error  are  corrected.  In  the  detection  mode,  cells  with  two  or  more  bit  error  are  discarded, 
and  require  retransmission.  Figure  2.6  depicts  how  error  correction  is  performed  at  the 
receiver  (de  Prycker,  M.,  1993,  p.  123). 


4.  ATM  Layer 

The  ATM  Layer  is  completely  independent  of  the  physical  medium  used  to 
transport  ATM  cells.  As  a  result,  it  is  also  fully  independent  of  the  physical  layer.  The 
ATM  layer  performs  the  following  main  functions  (de  Prycker,  M.  1993,  p.  115): 

♦  Multiplexing  and  demultiplexing  of  cells  of  different  connections  (identified  by 
different  VCI  and/or  VPI  values)  into  a  single  cell  stream  on  the  physical  layer. 

♦  Translating  the  cell  identifier,  which  is  required  in  most  cases  when  switching  a 
cell  from  one  physical  link  to  another,  in  an  ATM  switch  or  cross  connect. 
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♦  Providing  the  user  a  virtual  channel  connection  or  virtual  path  connection  vvith 
one  quality  of  service  class,  out  of  a  number  of  classes  supported  by  the 
network. 

♦  Managing  layer  types  using  information  in  the  cell  header. 

♦  Extracting  (adding)  the  cell  header  before  (after)  the  cell  is  delivered  to  (from) 
the  adaptation  layer. 

♦  Implementing  a  flow  control  mechanism  on  the  user-network  interface. 

5.  ATM  Adaptation  Layer 

The  ATM  Adaptation  Layer  (AAL)  enhances  the  services  provided  by  the  ATM 
layer  to  a  level  required  by  the  next  higher  layer.  It  is  subdivided  into  two  sublayers:  the 
segmentation  and  reassembly  sublayer  (SAR),  and  the  convergence  sublayer  (CS).  The 
primary  function  of  the  SAR  sublayer  is  segmentation  of  the  higher  layer  information  into  a 
size  suitable  for  the  payload  of  the  consecutive  ATM  cells  of  a  virtual  connection,  and  the 
inverse  operation,  reassembly  of  the  contents  of  the  cells  of  virtual  coimection  into  data 
units  to  be  delivered  to  the  higher  layer.  The  convergence  sublayer  performs  functions  like 
message  identification,  time/clock  recovery,  etc.  (dePrycker,  1993,  p.  115) 

The  AAL  provides  the  user  the  capability  to  send  various  types  of  information  over 
an  ATM  network  at  either  constant  or  variable  bit  rates.  The  end-to-end  connection 
established  to  transport  the  information  can  be  connection  or  connectionless  oriented.  The 
information  can  be  either  voice,  data,  video,  image,  or  even  a  combination  of  these  in 
multi-media  applications.  The  below  table  provides  the  classes  of  services  offered  and  the 
protocol  support  by  ATM  B-ISDN. 


Class: 

A 

B 

c 

D 

Example 

VoiceA^ideo 

Packet  Video 

Data  (SMDS) 

Connection  Mode 

Connection- 
Oriented  (C.O.) 

C.O. 

C.O. 

Connectionless 

Bit  Rate 

Constant 

Variable 

Variable 

Variable 

ATM 

Adaption  Layer 

AAL-l 

AAL-2 

AAL-3/4 

AAL-5 

AAL-3/4 

Table  2. 1  ATM  B-ISDN  Classes  of  Services 


6.  ATM  Connections 

Before  information  traverses  an  ATM  network,  a  connection  must  be  established. 
The  connection  setup  prior  to  the  sending  and  receiving  of  information  makes  ATM  a 
connection  oriented  network.  All  information  at  the  sending  node  will  use  the  same  "pipe" 
to  reach  the  receiving  node.  After  the  receiving  node  retrieves  all  the  information 
associated  with  the  transmission,  the  connection  is  terminated. 

a.  Virtual  Channels 

The  "pipe"  or  logical  connection  which  the  information  traverses  is  the 
virtual  channel.  These  channels  are  identified  by  the  VCI  in  the  header  of  each  ATM  cell. 
The  VCI  field  has  16  bits.  Theoretically,  this  allows  up  to  2’®  or  65,536  virtual  channels  in 
physical  connections.  Each  channel  can  be  assigned  various  speeds  (kilobits  per  second  to 
gigabits  per  second). 

b.  Virtual  Paths 

When  virtual  channels  have  the  same  origin  and  destination,  they  can  be 
consolidated  into  virtual  paths.  These  paths  are  defined  by  the  VPI  in  the  header  of  each 
ATM  cell.  The  VPI  field  is  8  bits  for  UNIs  and  12  bits  for  NNIs.  The  additional  four  bits 
replace  the  GFC  bits  which  are  not  required  for  NNIs.  Figure  2.7  depicts  the  relationship 
between  VCIs  and  VPIs  (de  Prycker,  M.,  1993,  p.  86).  The  bold  lines  between  the  ATM 
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nodes  represents  the  physical  connection  and  the  non-bold  lines  depicts  the  logical 
connection  (VCIs  and  VPIs)  which  are  established  and  tomdown  within  the  physical 
connections. 


Figure  2.7  ATM  Network  using  Virtual  Channels  and  Virtual  Paths 


In  Figure  2.7,  a  virtual  path  is  established  between  subscriber  A  and 
subscriber  C,  transporting  two  individual  connections,  each  with  a  separate  VCI.  Note 
that  the  VCI  values  used  (3  and  4  in  the  example)  are  NOT  translated  in  the  nodes,  which 
are  only  switching  on  the  VPI  field.  In  addition,  a  virtual  path  between  A  and  B  is 
semi-permanently  established,  using  VCI  values  1,  2,  and  3.  Another  interesting  point  is 
that  the  link  between  A  and  node  1,  uses  3  as  the  VCI  value  twice.  This  creates  no 
problems,  since  the  different  VPI  values  allow  the  two  endpoints  (A  and  node  1)  to 
discriminate  between  the  two  virtual  connections,  (de  Prycker,  M.,  1993,  p.  86) 
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C.  ATM  LAN  EMULATION 

1.  Overview 

When  the  10  Mbps  Ethernet  LAN  standard  was  finalized  over  15  years  ago,  one 
would  have  never  believed  that  10  Mbps  would  not  be  capable  of  efficiently  handling 
today's  applications  and  a  large  workgroup  of  users.  Though  the  16  Mbps  Token-Ring 
technology  is  faster  than  10  Mbps  Ethernet  networks,  the  Token-Ring  networks  still  is  not 
capable  of  efficiently  meeting  today's,  as  well  as  future,  application  demands.  Users  are 
now  competing  more  and  more  for  computing  resources  and  are  bringing  network  (LANs) 
to  a  crawl.  As  a  result,  thousands  of  users  have  lost  confidence  with  existing  "customer 
premise"  networks.  Many  have  resulted  to  loading  application  software  on  their  own 
computer  to  reduce  the  time  required  to  bring  up  an  application  such  as  WordPerfect, 
Lotus  123,  Excel,  and  Paradox. 

Because  of  the  demand  for  more  bandwidth  to  the  desktop,  and  the  development 
of  multi-media  applications,  industry  is  developing  new  technology  to  satisfy  user  needs. 
Some  technologies  are  based  on  traditional  shared  medium  (FDDI,  DQDB,  Fast  Ethernet), 
and  others  are  based  upon  a  switched  point-to-point  topology  (Switched  Ethernet,  ATM) 
(Newman,  P.,  1993,  p.  44). 

A  shared  medium  design  restricts  the  total  capacity  available  to  the  LAN  at  the 
speed  of  the  shared  medium.  This  circumscription  gets  expensive  at  high  speeds.  Also,  as 
more  users  are  added  to  the  shared  medium,  the  capacity  must  be  divided  between  the 
users.  For  example,  if  a  10  Mbps  Ethernet  LAN  supported  25  users,  and  all  25  users 
accessed  the  network  simultaneously,  the  average  throughput  per  user  would  be  400 
kilobits  per  second  (Kbps).  ATM  networks  do  not  have  this  limitation;  ATM  can  scale 
fi-om  small  multiplexers  to  very  large  switches  in  both  aggregate  capacity  and  number  of 
access  ports.  It  can  accommodate  access  ports  fi-om  low  speeds  to  very  high  speeds. 
ATM  is  also  designed  to  handle  multimedia  traffic.  Due  to  these  capabilities,  ATM  is 
heavily  considered  as  a  technology  that  should  support  traditional  LAN  services. 
(Newman,  P.,  1993,  p.  44) 
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To  make  ATM  to  the  desktop  more  appealing  to  users,  industry  had  to  consider 
the  installed  base  of  existing  LAN  protocols  and  applications.  The  majority  of  installed 
protocol  stacks  rely  on  facilities  provided  by  today's  LANs.  In  order  to  use  the  current 
base  of  existing  LAN  applications,  ATM  must  use  a  process  known  as  LAN  Emulation 
(LANE).  In  this  process,  ATM  emulates  services  of  existing  LANs  on  an  ATM  network 
without  the  need  of  any  change  in  the  ATM  terminal  equipment's  interface  to  the  media 
access  control  (MAC)  layer.  (Kavak,  N.,  1995,  p.  28) 

The  LANE  protocol  emulates  a  LAN  on  top  of  an  ATM  network.  The  protocol 
defines  the  mechanisms  to  emulate  either  an  IEEE  802.3  Ethernet  or  an  802.5  Token  Ring 
LAN.  Specifically,  the  LANE  protocol  defines  a  service  interface  for  higher  layer  (that  is, 
network  layer)  protocols,  which  is  identical  to  that  of  the  existing  LANs,  and  the  data  sent 
across  the  ATM  network  are  encapsulated  in  the  appropriate  LAN  MAC  packet  format 
(Alles,  A.,  1995,  p.  24).  This  does  imply  that  any  attempt  is  made  to  emulate  actual  MAC 
protocol  of  the  specific  LAN  concerned  (i.e.,  CSMA/CD  for  Ethernet  or  token  passing  for 
802.5). 

Figure  2.8  provides  an  illustration  of  the  LANE  protocol  architecture  (Alles,  A., 
1994,  p.  25). 


Figure  2.8  LANE  Protocol  Architecture 
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The  current  LANE  protocol  does  not  define  a  separate  encapsulation  for  FDDI. 
FDDI  packets  must  be  mapped  into  either  Ethernet  or  Token-Ring  emulated  LANs,  using 
existing  translational  bridging  techniques.  Fast  Ethernet  (100Base-T)  and  802.12 
(lOOVG-AnyLAN)  can  both  be  mapped  unchanged  into  either  the  Ethernet  or  Token-Ring 
LANE  formats  and  procedures,  as  appropriate,  since  they  use  the  same  packet  formats. 
(Alles,  A.,  1995,  p.  24) 

2.  Connectionless  Service  Implementation 

ATM  switches  use  connection  oriented  services  to  pass  information.  However, 
current  LAN  technologies  use  connectionless  services  as  a  method  of  communicating.  To 
address  this  difference,  ATM  LANs  use  connectionless  servers  (CLSFs)  to  offer 
connectionless  service  at  the  MAC  layer. 

In  its  simplest  form,  a  CLSF  is  a  packet  switch  attached  to  an  ATM  switch.  All 
virtual  channels  carrying  traffic  that  requires  a  connectionless  switching  service  is  directed 
by  the  ATM  switch  to  the  CLSF.  The  CLSF  are  connected  together  with  virtual  paths 
through  the  ATM  switch  to  form  a  "virtualWerlay  network.”  Figure  2.9  illustrate  the 
implementation  of  connectionless  data  service.  (Newman,  P.  "ATM  Local  Area 
Networks,"  1994,  p.  95) 
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3.  Emulated  LAN  Components 

The  LANE  protocol  defines  the  operation  of  a  single  emulated  system  LAN 
(ELAN).  Multiple  ELANs  may  coexist  simultaneously  on  a  single  ATM  network  since 
ATM  connections  do  not  collide.  A  single  ELAN  emulates  either  Ethernet  or  Token  Ring, 
and  consists  of  the  following  entities:  (AUes,  A.,  1995,  p.  26) 

♦  LAN  Emulation  Client  (LEG):  A  LEC  is  the  entity  in  an  end  system  that 
performs  data  forwarding,  address  resolution,  and  other  control  functions  fi^r  a 
single  end-system  within  a  single  ELAN.  A  LEC  also  provides  a  standard  LAN 
service  interface  to  any  higher  layer  entity  that  interfaces  to  the  LEC.  An  ATM 
NIC  or  LAN  switch  interfacing  to  an  ELAN  supports  a  single  LEC  for  each 
ELAN  to  which  they  are  connected.  An  end-system  that  connects  to  multiple 
ELANs  will  have  one  LEC  per  ELAN.  Each  LEC  is  identified  by  a  unique 
ATM  address,  and  is  associated  with  one  or  more  MAC  addresses  reachable 
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through  that  ATM  address.  In  the  case  of  an  ATM  NIC,  for  instance,  the  LEC 
may  be  associated  with  only  a  single  MAC  address,  while  in  the  case  of  a  LAN 
switch,  the  LEC  would  be  associated  with  all  the  MAC  addresses  reachable 
through  the  ports  of  that  LAN  switch  which  are  assigned  to  the  particular 
ELAN. 

♦  LAN  Emulation  Server  (LES):  The  LES  implements  the  control  function  for  a 
particular  ELAN.  There  is  only  one  logical  LES  per  ELAN,  and  to  belong  to  a 
particular  ELAN  means  to  have  a  control  relationship  with  that  ELAN'S 
particular  LES.  Each  LES  is  identified  by  a  unique  ATM  address. 

♦  Broadcast  and  Unknown  Server  (BUS):  The  BUS  is  a  multicast  server  that  is 
used  to  flood  unknown  destination  address  traffic,  and  forward  multicast  and 
broadcast  traffic  to  clients  within  a  particular  ELAN.  Each  LEC  is  associated 
with  only  a  single  BUS  per  ELAN,  but  there  may  be  multiple  BUSs  within  a 
particular  ELAN  that  communicate  and  coordinate  in  some  vendor-specific 
manner.  The  BUS  to  which  a  LEC  connects  is  associated  with  the  broadcast 
MAC  address.  In  the  LES,  this  is  associated  with  the  broadcast  MAC  address 
("all  ones"),  and  this  mapping  is  normally  configured  into  the  LES. 

♦  LAN  Emulation  Configuration  Server  (LECS):  The  LECS  is  an  entity  that 
assigns  individual  LANE  clients  to  particular  ELANs  by  directing  them  to  the 
LES  that  correspond  to  the  ELAN.  Locally,  there  is  one  LECS  per 
administrative  domain,  and  this  serves  all  ELANs  within  that  domain. 

Though  the  current  LANE  specification  define  two  types  of  ELAN,  (Ethernet  and 
Token-Ring),  the  specification  does  not  permit  direct  connectivity  between  an  Ethernet 
ELAN  and  a  Token-Ring  ELAN.  The  two  ELANs  must  interconnect  through  an  ATM 
router  which  acts  as  a  client  on  each  ELAN  (Alles,  A.,  1995,  p.26). 

Another  important  note  to  mention  is  that  the  aforementioned  server  components 
can  run  on  any  device  with  ATM  connectivity.  However,  for  the  purpose  of  reliability  and 
performance,  most  vendors  will  more  than  likely  implement  the  server  components  on 
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ATM  switches  or  routers,  rather  than  a  workstation  or  host.  An  illustration  of  LANE 
protocol  interfaces  are  provided  in  Figure  2.10. 


4.  Traffic  Management 

As  with  an  ATM  WAN,  ATM  LANs  will  more  than  likely  have  to  provide  two 
classes  of  traflBc,  guaranteed  and  best-effort.  Guaranteed  traflSc  is  traflBc  (e.g.,  video, 
voice)  for  which  a  certain  quality  of  service  (QoS)  (cell  delay,  cell  delay  variation,  cell 
priority,  cell  loss,  type  of  information  that  will  be  transmitted,  speed)  is  provided  by  the 
network.  The  guarantee  establishes  a  contract  between  the  trafiBc  source  and  the  network 
(Newman,  P.,  "Traffic  Management  for  ATM  Local  Area  Networks,"  1994,  p.  45). 
Before  the  contract  is  finalized,  and  a  connection  is  set  up  between  the  origin  and  the 
intended  destination,  the  network  will  query  itself  (traffic,  available  bandwidth)  to 


20 


determine  if  it  can  offer  the  requested  QoS.  The  network  will  also  monitor  the  trafiSc  to 
ensure  that  the  transmission  stays  within  the  contracted  parameters. 

The  network  ,or  switching  hardware,  must  ensure  that  QoS  for  guaranteed  traffic 
is  not  adversely  affected  by  best-effort  traffic.  This  can  be  accomplish  by  creating  two 
buffers  in  the  switch  hardware,  one  for  guaranteed  traffic  and  the  other  for  best-effort 
traffic.  The  queue  service  algorithm  always  serves  the  guaranteed  traffic  in  preference  to 
the  best-effort  traffic.  Figure  2.11  provides  a  general  illustration  of  the  two  buffers 
(Newman,  P.,  "Traffic  Management  for  ATM  Local  Area  Networks,"  1994,  p.  45). 


Guaranteed  Traffic 

Switch _ / 

Fabric  \ 


Best-effort 

Traffic 


Figure  2.11  Output  Buffer  with  Two  Classes  of  Traffic 

In  an  IEEE  802  LAN,  the  shared  medium  provides  the  shared  bandwidth  and  the 
MAC  protocol  is  the  arbitration  mechanism  by  which  the  bandwidth  is  shared  between  the 
contending  users.  In  an  ATM  switch,  each  output  port  is  a  pool  of  bandwidth  that  need  to 
be  shared  dynamically  between  all  connections  currently  sending  best-effort  traffic  across 
it.  Some  congestion  control  scheme  must  be  implemented  in  an  ATM  LAN  to  support  the 
statistical  sharing  of  bandwidth  between  competing  stations  without  prior  bandwidth 
reservation.  To  date,  three  approaches  are  available  for  congestion  control: 
over-provision  in  terms  of  bandwidth  or  buffers,  loss  mechanisms,  and  delay  mechanisms. 
(Newman,  P.  "ATM  Local  Area  Networks,"  1994,  p.  95) 
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Over-provision  has  its  congestion  limitations  in  both  bandwidth  and  buflfering. 
Bandwidth  is  fairly  obvious:  if  bandwidth  is  overly  allocated,  then  this  reduces  the 
capability  of  the  ATM  switch  to  provide  services  to  an  abundance  of  simultaneous  users. 
Regarding  buflfering,  if  the  delay  through  the  buffer  exceeds  the  retransmission  time-out  of 
the  higher  layer  protocols,  more  retransmission  traflBc  will  be  introduced  to  the  network 
while  the  network  is  congested. 

Loss  mechanisms  discard  cells  during  periods  of  congestion.  However,  this  leads 
to  a  problem  of  creating  more  traflBc  or  congestion  on  the  network.  Each  discarded  cell 
may  belong  to  different  packets.  As  a  result,  each  packet  must  be  retransmitted  and 
bandwidth  is  wasted  by  the  onward  transmission  of  the  remaining  cells  from  corrupted 
packets.  Various  approaches  have  been  explored  to  address  this  problem.  One  in 
particular  is  the  use  of  cell  loss  priority.  The  ATM  switch  would  discard  low  priority  cells 
rather  than  high  priority  cells.  This  approach  is  very  difficult  to  implement.  Methods 
cannot  be  visualized  as  to  how  data  traffic  could  be  coded  into  two  loss  priorities  at  the 
MAC  sublayer. 

Delay  mechanisms  use  negative  feedback  from  the  point  of  congestion  back 
towards  the  source  to  reduce  the  traffic  entering  the  network.  Forward  explicit  congestion 
notification  (FECN)  sends  a  congestion  indication  along  the  forward  data  path  to  the 
destination.  The  destination  then  takes  some  action  to  cause  the  source  to  reduce  its 
transmission  rate.  Backward  explicit  congestion  notification  (BECN)  sends  the  congestion 
indication  directly  back  to  the  source  along  a  return  path.  On  receipt  of  this  indication  the 
source  reduces  its  transmission  rate  directly.  BECN  can  respond  to  congestion  more 
rapidly  than  FECN  but  requires  congestion  notification  cells  to  be  inserted  into  the 
network.  On  the  other  hand,  FECN  can  simply  mark  a  bit  in  the  cell  header  as  it  passes 
through  the  point  of  congestion.  Other  delay  mechanisms  have  been  proposed  that  use 
credit  or  backpressure  on  each  virtual  connection,  on  a  linkj-by-link  basis  between  switches 
and  ultimately  back  to  the  source.  This  approach  offers  much  tighter  flow  control,  but  is 
considerably  more  complex  to  implement.  (Newman,  P.  "ATM  Local  Area  Networks," 
1994,  p.  96) 
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5.  LANE  and  Virtual  LANs 

Vendors  use  LANE  to  provide  virtual  LAN  services  on  an  ATM  network.  The 
virtual  LANs  are  implemented  on  switched  internets  using  a  combination  of  LAN 
switching  (bridging),  ATM  end  systems  (servers,  using  ATM  NICs),  and  routers  with 
ATM  interfaces  ("ATM  routers").  These  devices  are  all  connected  to  an  ELAN.  The 
ELAN  looks  and  functions  like  a  typical  LAN  except  for  the  bandwidth  as  far  as  either  end 
systems  attached  to  the  LAN  ports  on  the  LAN  switches,  or  the  higher  layer  protocols 
operating  within  the  ATM  hosts  or  routers  are  concerned  (AUes,  A.,  1995,  p.  3 1). 

Implementing  a  virtual  LAN  using  LANE  has  many  advantages;  one  in  particular  is 
network  management.  Through  network  management,  and  the  use  of  mechanisms  such  as 
the  LECs,  the  network  administrator  can  set  up  several  ELANs  across  a  single  ATM 
backbone,  and  then  assign  LAN  switch  ports  or  ATM  hosts  to  the  different  ELANs, 
independent  of  the  physical  location  of  the  devices  (Alles,  A.,  1995,  p.  3 1).  This  process 
removes  the  physical  location  limitation  of  current  LANs.  As  a  result,  the  physical 
location  of  the  devices  no  longer  determines  the  LAN  segment  to  which  the  devices  can  be 
connected. 

Virtual  LANs  also  give  the  network  administrator  the  ability  to  change  or 
reconfigure  virtual  networks  without  changing  the  cabling  plantas  the  organization  work 
flows  or  processes  change.  This  helps  reduce  the  cost  of  moving  or  adding  personnel. 

Though  virtual  LANs  have  great  benefits,  there  is  also  a  downside.  Because 
LANE  is  a  LAN  bridging  standard,  ELANs  are  susceptible  to  broadcast  storms.  This 
tends  to  limit  ELANs  to  small  workgroup.  As  a  result,  large  networks  are  likely  to 
support  a  large  number  of  virtual  LANs  (ELANs). 

An  illustration  of  connectivity  between  ELANs  are  provided  in  the  Figure  2. 12. 
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Figure  2. 12  ATM  LAN  Segments  (Virtual  LANs) 

D.  ATM  STANDARDIZATION  PROCESS 

Prior  to  October  1991,  ATM  or  B-ISDN  standards  were  established  by  standard 
making  bodies  such  as  the  International  Telecommunications  Union  (ITU)  (formerly  the 
International  Telegraph  and  Telephone  Consultative  Committee  (CCITT)),  and  the 
American  National  Standards  Institute  (ANSI).  These  organization  primarily  focused  on 
future  public  B-ISDN  networks  and  often  took  years  to  finalize  standards.  Manufacturers 
became  concerned  that  high  bandwidths  requirements  for  end  users  (customer  premises 
equipment  (CPE)  and  private  switching  equipment)  would  become  more  prevalent  than  the 
need  for  high  bandwidth  for  public  networks  and  wanted  to  expedite  the  standards  making 


process.  As  a  result,  these  manufacturers  (CPE  vendors,  public  equipment  vendors), 
telecommunication  operators,  and  users  formed  the  ATM  Forum  which  is  the  "premier" 
ATM  standards  body. 

The  ATM  Forum  has  more  than  700  member  companies,  and  it  has  five 
committees:  the  Technical  Committee,  three  Marketing  Committees  for  North  America, 
Europe  and  Asia-Pacific,  and  an  Enterprise  Network  Roundtable. 

The  Technical  Committee  is  a  single  worldwide  committee  and  primarily  focus  on 
promoting  a  single  set  of  specifications  to  ensure  interoperability  between  all  vendors  as 
ATM  products  and  services  become  available  (http:/www.atmforum.com/atmforum/ 
atm_introduction.html,  p.  1).  This  committee  has  done  work  on  User-Network  Interface, 
Data  Exchange  Interface  (defines  how  existing  network  equipment  such  as  bridges, 
routers,  and  hubs  can  act  as  fi-ont-end  processors  to  an  ATM  network),  LAN  Emulation, 
and  Broadband  Inter-Carrier  Interface  specifications.  The  Technical  Committee  is  also 
working  on  key  areas  such  as  traffic  management,  signaling,  physical  interfaces,  network 
management,  service  aspects  and  apphcations,  and  testing.  Appendix  A  is  a  Techiucal 
Committee  update  which  provides  a  status  report  of  current  work  items  as  of  December 
1995  (Hold,  D.  F.,  1995,  p.ll). 

The  ATM  Market  Awareness  and  Education  Committee  (MA&E)  functions  as  the 
public  affairs  agencies  for  the  ATM  Forum.  Their  primary  focus  is  to  provide  marketing 
and  educational  services  for  the  understanding  and  acceptance  of  ATM  technology. 

The  Enterprise  Network  Roundtable  Committee  consists  of  end-users.  This 
committee  interacts  on  a  regular  basis  with  (MA&E)  to  ensure  that  ATM  technical 
specifications  meet  their  needs. 
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E.  ATM  IMPLEMENTATION 


Because  ATM  is  scaleable  from  a  LAN  environment  to  a  WAN  environment,  it  can 
be  applied  in  a  WAN,  MAN,  or  LAN.  The  technology  can  also  be  used  in  all  three 
environments  simultaneously,  thus  creating  a  "pure"  ATM  network.  The  next  three 
sub-subsections  discuss  ATM  networks  in  WAN,  MAN,  and  LAN  environments. 

1.  ATM  WAN 

ATM  over  a  WAN  provide  greater  bandwidth  over  long  hauls.  It  gives  the  user 
the  capability  to  transmit  data,  voice,  and  video  over  one  ubiquitous  network,  instead  of 
having  three  separate  networks  for  voice,  data,  and  video.  Figure  2.13  shows  the  use  of 
ATM  in  a  wide  area. 
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2. 


ATM  MAN 


A  MAN  is  a  network  capable  of  providing  high  speed  (more  than  1  Mbps) 
switched  end-to-end  connectivity  across  distances  ranging  from  5  to  50  km.  This  allows  a 
MAN  to  span  an  entire  university  campus,  an  entire  city,  or  an  office  park.  Like  an  ATM 
WAN,  an  ATM  MAN  allows  the  simultaneous  carrying  of  different  types  of  traffic  such  as 
data,  voice,  and  video.  These  characteristics  make  the  MAN  complementary  to  the 
definition  of  B-ISDN.  (de  Prycker,  M.,  1993,  p.  259). 

The  Advanced  Technology  Demonstration  Network  (ATDnet),  an  ATM  MAN,  is 
currently  operational  in  the  Washington  DC  metropolitan  area.  ATDnet  is  a  high 
performance  networking  testbed  which  is  intended  to  represent  a  possible  future  MAN.  It 
uses  ATM  and  Synchronous  Optical  Network  (SONET)  technologies  to  connect  six 
federal  Agencies;  the  Advance  Research  Project  Agency  (ARP A),  the  Defense  Information 
Systems  Activity  (DISA),  the  Defense  Intelligence  Agency  (DIA),  the  National 
Aeronautics  and  Space  Administration  (NASA),  the  Naval  research  Laboratory  (NRL), 
and  the  National  Security  Agency  (NSA). 

The  ATDnet  concept  is  to  interconnect  these  agencies  with  high  speed  fiber  optic 
transmission  media,  and  to  overlay  these  media  with  SONET  and  ATM  protocols.  The 
initial  deployment  operated  at  OC-48  data  rates  (approximately  2.4  gigibits/second),  but  is 
designed  to  scale  upwards  to  technology-limited  data  rates.  Pair-wise  and  multiple  party 
research  initiatives  and  experiments  are  planned  over  the  lifetime  of  the  testbed. 
Experimental  testing  of  the  bitways  and  a  diversity  of  service  and  applications  experiments 
are  intended  to  gain  insight  into  the  potential  of  this  new  performance  level  (Edicott,  D., 
1994). 

Figure  2.14,  on  the  next  page,  depicts  the  testing  of  the  ATM  MAN  during  1995. 
Following  the  installation  of  the  additional  pair  of  fibers,  each  government  site  had 
four-fiber,  OC-48  SONET  service  to  the  add/drop  multiplexer  (ADM),  a  Metropolitan 
Point  of  Presence  (MPOP).  Initially,  each  on-site  MPOP  had  two  OC-3  (155  MBits/sec) 
service  connections  to  on-premise  ATM  smtches. 
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Each  participating  agency  in  the  ATDnet  is  responsible  for  on-premise  routing,  and 
local  distribution  of  ATM  and  SONET  traffic  is  the  individual  responsibility  of  each 
participating  agency  (Edicott,  D.,  1994).  Typical  configurations  may  include  ATM  service 
to  scientific/engineering  workstations,  databases  and  file  servers,  high  performance 
computers,  and  high  resolution,  and  3D  display  devices.  Figure  2.15  provides  a  general 
idea  of  the  ATM  configuration  for  DIS  A. 
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DISA  ATDNet  SITE  CONFIGURATION 


Figure  2.15  DISA  ATDnet  Site  Configuration 


3.  ATM  LAN 

Implementing  ATM  on  a  LAN  will  give  the  user  tremendous  bandwidth  at  the 
desktop.  Instead  of  the  bandwidth  being  shared  between  the  users  on  the  LAN,  the  vast 
bandwidth  will  be  dedicated  to  the  user  during  data  transfer.  This  is  accomplished  by 
replacing  the  shared  medium  with  a  centralized  switch.  By  having  additional  dedicated 
bandwidth  to  each  workstation  or  personal  computer,  users  are  capable  of  accessing  more 
powerful  applications  such  as  video  teleconferencing  to  the  desktop  and  shared 
multi-media  applications.  Figure  2. 16  illustrates  an  ATM  LAN. 


Figure  2.16  ATM  LAN 


F.  CHAPTER  SUMMARY 

ATM  has  numerous  advantageous  over  existing  networking  technologies  (frame 
relay,  ISDN,  shared  media).  One  in  particular  is  ATMs  ability  to  service  different  types  of 
information  (data,  voice,  and  video).  ATM  is  also  scaleable  in  speed  (Mbps  to  Gbps),  and 
geography  (local,  metropolitan,  and  wide  areas).  Because  ATM  is  scaleable  in  the  local, 
metropolitan,  and  wide  area,  network  management  is  simplified.  The  same  set  of  tools  can 
be  used  on  the  various  sizes  of  the  network.  This  reduces  both  training  cost  and  time. 
Another  key  point  in  ATMs  favor  is  its  ability  to  dedicate  bandwidth  to  each  end-unit, 
instead  of  having  to  share  bandwidth  like  Ethernet  and  Token-Ring  technology.  Finally, 
ATM  can  run  on  existing  cabling  plants  (twisted  pair,  coax,  and  fiber).  This  allows 
end-users  the  usage  of  their  current  cabling  plant  instead  of  having  to  replace  it. 
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m.  ATM  IMPLEMENTATION  ISSUES 


A.  INTRODUCTION 

1.  Puqiose  of  Chapter 

This  chapter  discusses  implementation  issues  affecting  the  ATM  technology  as  a 
whole.  Many  of  the  issues  relate  to  ATM  LANs  and  how  they  function.  Some  issues  are 
only  applicable  to  ATM  backbones,  MANs,  and  WANs.  However,  because  of  their 
significance,  and  the  possibility  of  connecting  a  redesigned  Systems  Management's 
laboratory  LAN  to  the  Naval  Postgraduate  School  campus  backbone,  these  issues  are  also 
discussed. 

Because  ATM  standards  are  evolving,  many  implementation  issues  discussed  in 
this  chapter  may  be  resolved  by  the  time  this  thesis  is  published. 

2.  Standardization 

Given  ATM's  capabilities,  it  alone  holds  the  promise  of  a  single  technology 
supporting  high  performance  data,  voice,  and  video  services  through  the  seamless 
integration  of  local  and  wide  area  networks,  including  those  in  the  tactical  theater  of 
operations. 

As  with  any  new  technology,  risk  is  a  major  factor,  and  this  is  particular  true  with 
ATM.  Standards  are  still  evolving,  and  many  manufacturers  have  been  reluctant  to  wait 
for  concrete  specifications.  Due  to  this,  many  products  have  been  marketed  that  only  have 
the  capability  to  operate  with  the  manufacturer's,  or  very  few  vendors',  equipment.  Many 
of  these  "stove  pipe"  network  products  are  headed  for  the  orphanage  once  a  real  ATM 
specification  set  is  agreed  on,  because  they  will  face  software  incompatibility  with  many  of 
the  high-bandwidth  applications  that  drive  the  demand  for  ATM.  (Gallagher,  S.,  1995,  p. 
40) 

Areas  in  which  standards  have  not  been  established,  or  still  evolving  are  LAN 
emulation,  signaling,  congestion  and  flow  control,  Internet  Protocol  (IP)  over  ATM, 
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firewalls,  and  AAL  compatibility.  The  subsequent  sections  of  this  chapter  discuss  these 
issues. 

B.  LAN  EMULATION 

1.  Problem 

As  discussed  in  the  previous  chapter,  the  function  of  the  LANE  protocol  is  to 
emulate  a  LAN  on  top  of  an  ATM  network.  The  protocol  makes  the  ATM  network 
behave  like  an  Ethernet  or  Token-Ring  network,  even  though,  the  network  is  running  at  a 
much  faster  bit  rate. 

The  current  LANE  protocols  (Phase  1)  specify  only  the  operation  of  the  LAN 
Emulation  User-to-Network  Interface  (LUNI)  between  a  LEG  and  the  network  providing 
the  LANE  service.  No  specifications  have  been  finalized  for  the  functioning  of  the  LAN 
Emulation  Network-to-Network  Interface  (LNNI).  The  LNNI  operates  between  the 
server  components  within  a  single  ELAN  system.  The  Phase  1  LANE  protocols  also  do 
not  allow  for  the  standard  support  of  multiple  LESs  or  BUSs  within  an  ELAN.  As  a 
result,  these  components  are  a  single  point  of  failure  and  a  potential  bottleneck.  The 
interactions  between  each  of  the  server  components  in  the  LANE  Phase  1  protocol  are 
currently  left  unspecified,  and  will  be  implemented  in  a  proprietary  manner  by  vendors. 
(AUes,  A.,  1995,  p.  26) 

Figure  3 . 1  illustrates  of  the  LUNI  and  LNNI  interfaces. 
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Figure  3.1  LANE  Protocol  Interfaces 


2.  Projected  Release  of  LNNI  Standard 

The  ATM  Forum  is  currently  working  on  a  Phase  2  LANE  protocol.  This 
protocol  will  specify  LNNI  protocols  to  allow  for  redundant  LESs  and  replicated  BUSs. 
The  LNNI  protocols  will  specify  open  interfaces  between  the  various  LANE  server 
entities  (LES/LES,  LES/LECS,  and  BUS/BUS).  The  protocols  will  also  allow  for 
hierarchies  of  BUSs  for  greater  scalability  within  ELANs.  The  projected  completion  data 
of  the  LNNI  protocols  is  1996. 
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c. 


NETWORK  MANAGEMENT 


1.  Overview 

Today's  network  management  architectures  and  tools  are  not  designed  to  handle 
the  speed  and  complexity  of  ATM  networks.  These  management  solutions  are  developed 
to  manage  router  or  time  division  multiplexing  (TDM)  based  networks,  and  cannot  meet 
the  critical  requirements  to  control  and  operate  an  ATM  network. 

ATM  fundamentally  changes  the  landscape  of  today's  networks.  The 
connection-oriented  environment,  varying  classes  of  services,  and  higher  volume  of 
multiple  traffic  types  differ  significantly  fi'om  yesterday's  staticly  configured,  standalone 
networks.  As  a  result,  ATM  networks  require  a  new  management  model,  one  which  takes 
these  differences  into  account.  (Alexander,  P.,  1995,  p.  47) 

2.  Problem 

With  the  virtual  networking  capabilities  associated  with  ATM,  the  traditional 
physical  and  logical  network  management  capabilities  are  greatly  complicated  by  the 
addition  of  voice  and  video  over  the  same  network  infrastructure.  Thus,  the  entire 
network  must  be  perceived  as  one  entity,  not  as  multiple  networks.  Network  managers 
will  no  longer  be  able  to  troubleshoot  their  ATM-based  network  like  they  do  today  on 
shared  media  LANs  by  only  attaching  a  protocol  analyzer.  Furthermore,  with  the 
currently  envisioned  corporate  enterprise  networks  where  the  management  domain  spans 
fi'om  the  desktop  to  the  wide  area,  high  volumes  of  network  management  and  control  data 
coupled  with  connection-oriented  environment  make  the  problems  extremely  more 
complex.  More  and  more,  users  are  discovering  that  managing  the  switched  ATM 
environment  with  a  single  Unix-based  simple  network  management  protocol  (SNMP) 
system  is  becoming  impossible.  In  addition,  SNMP  itself  raises  issues  of  security, 
scalability,  and  efficiency.  (Federline,  G.  E.,  1995,  p.  70) 

The  new  challenges  ATM  network  management  applications  must  address  are 
multipoint  connectivity,  virtual  connections,  multiple  classes  of  services,  and  high-speed 
cell  network.  If  these  areas  are  not  addressed,  the  ATM  network  will  run  inefficiently  and 
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ineflfectively.  Also,  ATM's  vast  capabilities  over  current  shared-medium  networks  will  not 
be  as  great.  A  brief  summary  of  the  areas  that  should  be  addressed  are  provided  in  the 
following  sub-subsections  ( Alexander,  P.,  1995,  p.  48). 

a.  Multipoint  Connectivity 

ATM  is  a  multipoint  network  architecture.  Managing  the  network  means 
managing  multiple  links  from  each  switch,  and  multiple  paths  throughout  the  network. 
The  task  of  managing  multipoint  connections  in  a  WAN  that  uses  an  underlying  TDM 
network  has  been  largely  performed  be  routers.  This  two-tiered  management  approach 
does  not  solve  the  problem  of  expensive,  wasted  bandwidth  in  the  router  portion  of  the 
network;  it  simply  increases  the  complexity  of  the  overall  management  task. 

b.  Virtual  Connections 

Each  connection  in  a  TDM  network  is  a  physical  link  carrying  several 
channels  defined  through  the  process  of  time  division  multiplexing.  ATM  networks  use 
virtual  connections  defined  by  virtual  path  and  virtual  channels  identifiers  carried  in  each 
cell.  These  virtual  connections  typically  use  several  dijBferent  physical  links  within  the 
network,  requiring  much  more  sophisticated  service  provisioning  than  TDM  and 
router-TDM  networks. 

c.  Multiple  Classes  of  Service 

Each  ATM  class  of  service  is  defined  be  specified  quality  of  services  (QoS) 
parameters  and  guarantees.  Every  virtual  connection  has  a  specified  guarantee  of  service, 
and  each  must  be  managed  from  end-to-end,  based  on  the  requisite  QoS.  At  the  same 
time,  an  individual  connection's  class  of  service  must  be  managed  in  relation  to  other 
virtual  connections  in  the  network  using  diflferent  classes  of  service.  Carriers  and  large 
enterprise  network  operators  are  no  longer  simply  managing  physical  connections,  but  are 
now  responsible  for  assuring  the  quality  of  many  virtual  connections. 
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d.  High-Speed  Cell  Network 

As  discussed  in  the  previous  chapter,  ATM  services  use  small,  fixed-length 
cells  running  over  a  high-speed  transmission  infi'astructure.  This  poses  three  challenges: 

♦  A  problem  in  one  part  of  the  network  can  aflfect  a  large  portion  of  the  network 
or  even  the  entire  network  before  it  can  be  reported  to  the  central  management 
station.  In  this  situation,  the  network  must  be  capable  of  addressing  the 
problem  before  the  information  reaches  the  management  station. 

♦  The  network  management  system  must  be  capable  of  handling  a  large  number 
of  fault  messages  stemming  fi-om  a  single  fault.  Broadcasting  all  fault 
messages  to  all  management  stations  in  the  network  can  itself  cause 
congestion.  A  different  fault  reporting  procedure  is  required. 

♦  A  large  amount  of  data  must  be  collected  and  reported  to  provide  useful 
information  about  network  trends  and  events  for  billing,  analysis,  and  planning. 
SNMP  is  not  capable  of  forwarding  this  data  to  central  management  for 
efficient  storage  and  processing. 

3.  Projected  Resolution  of  ATM  Network  Management 

No  date  has  been  set  as  to  when  complete  ATM  standards  and  specifications  for 
network  management  will  be  released.  Also,  network  management,  though  it  is  important, 
is  not  a  priority  on  the  ATM  Forum  agenda.  Because  the  ATM  Forum  has  not  shown  a 
critical  interest  in  network  management,  vendors  are  designing  their  own  network 
management  protocols  to  address  the  aforementioned  potential  network  management 
problems,  and  to  meet  customers'  needs.  These  actions  will  result  in  compatibility  and 
interoperability  problems  as  ATM  WANs  are  connected.  The  WANs  will  consist  of 
multi-vendor  products,  and  if  these  products  use  various  network  management  functions 
with  non-standard  protocols  and  interfaces,  the  users  will  not  be  able  to  effectively 
manage  end-to-end  connectivity  across  the  network.  Nor  will  the  user  be  able  to  access 
the  level  of  activity  analysis  necessary  for  effective  network  planning  (Alexander,  P.,  1995, 
p.  49). 
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D.  SIGNALING 


1.  Overview 

Before  any  information  exchanges  between  end  points,  some  type  of  signaling  is 
performed  to  setup  connectivity  to  establish  virtual  circuits.  This  signaling  is  initiated  by 
the  requesting  user  for  negotiation  with  the  network  with  respect  to  available  resources 
(VCIATI,  throughput,  and  QoS).  The  signaling  is  also  performed  over  a  separate 
signaling  virtual  channel. 

In  order  for  the  signaling  to  occur,  the  user  and  the  network  must  understand  the 
request  and  the  response.  To  do  this,  standards  are  a  must.  A  set  of  signaling  standards 
have  been  established,  and  they  are  the  foundation  upon  which  switched  ATM  services 
will  be  built. 

While  the  initial  standards  have  some  limitations,  and  can  only  cope  with  relatively 
simple  calls,  they  form  a  starting  point  from  which  manufacturers  and  operators  can  begin 
to  offer  switched  services  on  their  ATM  networks.  (Jeffrey,  M.,  1994,  p.  1) 

2.  Problem 

The  ATM  Forum  published  the  first  signaling  standard,  the  User  Network 
Interface  (UNI)  version  3.0.  This  standard  included  a  basic  signaling  protocol  for  LAN 
environments  with  local  ATM  switches  and  terminals.  The  ITU's  UNI  protocol  has  been 
completed  in  ITU-T  Recommendation  Q.2391  (previously  known  as  Q.93B),  and  is 
closely  aligned  with  UNI  v3,  but  is  designed  for  communicating  with  public  networks. 

UNI  v3  and  Q.2391  are  similar  in  that  they  only  support  the  "Release  1"  service. 
This  is  limited  to  simple  ATM  calls  with  a  single  connection  to  a  single  party  (Type  1 
connection).  Also,  the  bandwidth  for  the  call  is  specified  by  the  caller  and  cannot  be 
negotiated  with  the  called  party,  nor  can  the  bandwidth  be  changed  during  the  life  of  the 
call.  This  basic  service  is  sufficient  for  many  purposes,  including  LAN  intercoimect  and 
the  transport  of  most  POTS  and  ISDN  services.  However,  the  service  is  lacking  when  it 
comes  to  using  the  network  for  multimedia  applications  such  as  video-on-demand. 
(Jeffrey,  M.,  1994,  p.  1) 
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3.  Projected  Release  of  Complete  Signaling  Standards 

Following  the  release  of  "Release  1,"  the  ITU  begin  defining  the  requirements  for 
the  subsequent  stages.  For  manageability  reasons,  the  stages  have  been  segregated  into 
Capability  Sets.  The  next  stage  is  the  design  and  formulation  of  protocols  for  Capability 
Set  2  (CS2).  CS2  protocols  will  be  capable  of  the  following: 

♦  Negotiation  and  Modification  -  The  calling  party  will  be  able  to  offer  the  called 
party  a  choice  of  bandwidth  options  rather  than  the  "take  it  or  leave  it" 
provided  by  Release  1 . 

♦  Point-to-Multipoint  (Type  2)  Connections  -  The  ATM  Forum's  UNI  v3 
protocol  supports  limited  point-to-multipoint  connection.  As  a  result,  the 
ITU's  will  more  than  likely  adopt  this  approach  to  be  compatible. 

♦  Multi-Connection  Calls  -  CS2  will  include  the  support  for  many  point-to-point 
connections  in  the  same  call.  This  will  allow  the  transport  of  service 
components  (within  a  multimedia  call)  over  bearers  with  appropriate 
bandAvidth  and  QoS. 

♦  Multiple  Multipoint  Connections  -  This  signaling  protocol  will  provide  ATM 
switches  the  ability  to  support  a  mixture  of  point-to-point,  and  point-to- 
multipoint  connections  in  the  same  call.  Some  of  the  connections  will  not 
originate  fi-om  the  same  source  as  others. 

♦  Multipoint-to-Point  Connections  -  This  will  allow  "fan-in"  connectivity. 

♦  All-points  to  All-points  -  to  provide  a  "bus"  like  interface  where  all  ATM  cells 
are  copied  to  all  parties  on  the  connection. 

The  final  stage  on  the  signaling  protocols  is  Capability  Set  3  (CSS).  These 
protocols  will  oriented  toward  new  intelligence  and  services.  Some  of  the  services  include 
the  following: 

♦  Internetworking  with  the  Intelligent  Network  -  This  will  allow  the 
implementation  of  Freephone  and  Selective  Redirection  for  ATM  terminals. 
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♦  Embedded  Multimedia  Functions. 

♦  True  Broadcast  Service  -  This  feature  allows  the  support  of  Cable-TV  style 
broadcast  services  over  ATM  networks. 

♦  Evolution  towards  Telecommunications  Information  Network  Architecture 
(TINA)  -  This  protocol  allows  the  construction  of  future  network  control 
architecture  from  distributed  computing  principles. 

The  CS2  capabilities  should  be  available  in  1995.  Studies  have  begun  on  the 
requirements  for  CSS.  The  signaling  protocols  should  support  CSS  functions  in  1996  or 
1997. 


E.  CONGESTION  AND  FLOW  CONTROL 

1.  Problem 

Congestion  control  techniques  are  of  utmost  importance  in  an  ATM  network. 
Without  these  techniques,  user  traffic  on  the  network  could  exceed  the  capacity  of  the 
ATM  switches.  This  traffic  overload  would  cause  the  ATM  switch  memory  buffers  to 
overflow,  resulting  in  cell  loss.  The  cell  loss  may  require  the  retransmission  of  thousands 
of  cells. 

Congestion-induced  cell  loss  is  more  difficult  to  prevent  in  an  ATM  network  than 
in  networks  using  "today's"  technology  (shared  medium),  such  as  an  Ethernet  network.  An 
Ethernet  network  uses  the  MAC  to  help  prevent  loss  because  hosts  sense  the  network 
before  transmitting  data  to  prevent  or  minimize  collisions.  In  contrast,  on  an  ATM 
network  each  host  is  connected  to  the  switch  using  dedicated  links.  These  links  cannot 
sense  if  cross  traffic  will  be  encountered  at  intermediate  switches.  Since  switch  buffering 
is  limited,  and  the  transmission  rate  is  fixed,  buffer  overflow  can  easily  happen. 
(Brustoloni,  Jose'  Carlos,  1994,  p.  324) 

The  complexity  of  the  cell  loss  problem  is  compounded  by  the  limited  number  of 
overhead  bits  available  to  exert  control  over  the  flow  of  user  cells.  This  area  is  currently 
the  subject  of  intense  research,  and  no  consensus  has  emerged  for  a  full-blown  traffic  and 
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congestion  control  strategy.  Accordingly,  ITU-T  has  defined  a  restricted  initial  set  of 
traffic  and  congestion  control  capabilities  aiming  at  simple  mechanisms  and  realistic 
network  eflSciency;  these  are  specified  in  1.371.  The  ATM  Forum  has  published  a 
somewhat  more  advanced  version  of  this  set  in  the  ATM  UNI  Specification  3.0.  [Stalling, 
W.,  "ATM  Congestion  Control:  A  Practical  Issue  for  Users  and  Providers,"  1995,  p.  34] 

2.  Release  of  Congestion  and  Flow  Control  Standard 

The  ATM  Forum's  congestion  control  standard  was  decided  between  two 
solutions,  a  credit-based  scheme  and  a  rate-based  scheme.  The  credit-based  solution 
requires  window  flow  control  on  a  per-link,  per-VC  (virtual  connection)  basis.  Each  link 
has  a  sender  node  and  a  receiver  node  that  maintain  a  separate  queue  for  each  VC.  The 
receiver  determines  the  number  of  cells  the  sender  can  transmit  by  monitoring  the  queues 
on  each  VC,  then  issues  a  "credit"  that  determines  how  much  data  the  sender  can  transmit. 

The  rate-based  scheme  provided  end-to-end  control  using  single-bit  feedback.  The 
switch  monitors  the  network  by  using  the  feedback  bits.  When  congestion  is  detected,  the 
switch  adjusts  the  data  rate  until  the  heavy  traffic  goes  away. 

The  Forum  selected  the  credit-based  scheme  because  it  allows  zero  cell  loss,  while 
the  rate-based  scheme  requires  that  the  switch  be  capable  of  sufficient  buffering  to  prevent 
cell  loss.  (Chemicoff,  David  P.,  1995,  p.  N3) 

F.  IP  OVER  ATM 

1.  Overview 

IP  runs  over  various  transmission  media,  including  Ethernet,  Token-Ring,  Fiber 
Distributed  Data  Interface  (FDDI),  X.25,  Frame  Relay,  Switched  Multimegabit  Data 
Service  (SMDS),  and  many  others.  Now  procedures  must  be  formalized  to  run  IP  over 
ATM. 

IP  is  the  "glue"  which  allows  the  variety  of  protocols  to  communicate  across 
networks  or  the  Internet.  Each  protocol  can  be  viewed  as  running  in  its  own  subnet.  The 
subnets  are  connected  by  routers  to  form  the  internet.  As  shown  in  Figure  3.2,  the 

sending  host  computer  formats  (encapsulates)  an  IP  packet  to  send  to  the  receiving  host. 
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This  IP  packet  is  encapsulated  within  the  subnet  protocol  of  subnet  A  and  delivered  to  the 
router  between  subnets  A  and  B.  The  router  strips  off  subnet  As  protocol  information, 
and  retrieves  the  IP  packet.  The  packet  is  then  encapsulated  in  subnet  B's  protocol.  This 
process  continues  until  the  original  IP  packet  reaches  the  receiving  host. 


Figure  3.2  An  Internet  with  Four  Subnets 


2.  Problem 

The  primary  problem  or  difference  between  IP  and  ATM  is  that  IP  is 
connectionless  oriented  and  ATM  is  connection  oriented.  On  an  IP  network,  no 
connection  is  set  up  before  any  information  is  sent  from  the  sending  node  to  the  receiving 
node.  Also,  the  information  or  packets  may  traverse  different  paths  before  reaching  the 
destination.  At  the  destination,  the  packets  are  resequenced  and  reassembled  to  obtain 
the  original  message. 

On  an  ATM  network,  a  connection  or  virtual  path  is  established  between  the  end 
points  before  the  sending  host  transmit  information  down  the  path.  The  information  or 
cells  arrive  at  the  destination  in  the  same  order  that  they  were  transmitted.  Therefore,  no 
resequencing  is  necessary. 
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Another  difference  between  IP  and  ATM  is  the  use  of  addresses.  IP  uses 
addresses  as  a  means  of  sending  packets  to  the  appropriate  destination.  ATM  does  not 
use  addresses.  Instead,  it  uses  virtual  paths  and  virtual  channels. 

3.  Projected  Release  of  IP  over  ATM  Standard 

A  number  of  protocols  other  then  IP  have  already  been  standardized  to  operate 
over  ATM  (SMDS  and  frame  relay).  Technically,  IP  can  run  over  one  of  these  protocols 
over  ATM.  For  example,  if  an  organization  already  has  frame  relay  routers  in  place  using 
lease  lines,  the  lease  lines  could  be  replaced  by  ATM  service  using  ATM  data  service  units 
(DSUs),  which  provide  a  router-compatible  interface.  (Witt,  Michael,  1995,  p.  54) 

Another  alternative  of  running  IP  over  ATM  is  to  change  or  not  use  IP.  This  step 
would  allow  direct  mapping  between  TCP  and  connection-oriented  services.  Though  the 
method  may  have  some  advantages,  it  is  a  big  step  away  from  the  TCP/IP  architecture. 
As  a  result,  this  alternative  will  more  than  likely  not  be  chosen. 

The  Internet  Engineering  Task  Force  (IETF)  IP  over  ATM  working  group  is 
currently  writing  proposed  standards  for  IP  over  ATM.  The  working  group  fielded  two 
draft  standards  or  request  for  comments  (RFC)  that  address  running  IP  over  ATM. 

RFC  1483,  "Multiprotocol  Encapsulation  over  ATM  Adaption  Layer  5,"  discusses 
a  number  of  different  protocols  that  may  be  either  routed  or  bridged  over  ATM  networks. 
This  draft  covers  protocol  multiplexing  and  encapsulation  issues.  It  defines  two  possible 
methods  of  multiplexing,  and  specifies  the  encapsulation  format  to  be  used  with  each 
method  (Witt,  Michael,  1995,  p.  54). 

RFC  1577,  "Classical  IP  and  ARP  over  ATM,"  addresses  IP  over  ATM 
specifically.  It  uses  the  term  "classical  model"  to  describe  ATM  integrated  with  IP  as  a 
standard  subnet  protocol.  This  protocol  would  match  the  IP  addresses  to  their 
corresponding  ATM  addresses  (Alles,  A.,  1995,  p.  36). 

No  projected  date  has  been  set  as  to  when  the  IP  over  ATM  standard  will  be 
completed.  Because  the  IETF  is  independent  of  the  ATM  Forum  and  anyone  can  be  a 
member  of  the  ITEF,  it  may  be  sometime  before  the  standard  is  released. 
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G.  APPLICATION  PROGRAMMING  INTERFACE  (API) 


1.  Problem 

Vendors  and  users  have  two  varying  views  of  the  use  of  ATM  technology.  The 
manufacturers  feel  that  the  technology  should  be  used  to  increase  bandwidth  in  corporate 
LANs  and  WANs,  while  users  envision  ATM  being  extended  to  the  desktop. 

Though  these  views  have  "opposite”  poles,  both  parties  agree  that  in  order  to 
increase  the  demand  of  ATM  to  the  desktop,  a  new  class  of  applications  must  be 
developed  to  exploit  the  ATM  technology.  These  new  applications  would  use  services 
provided  by  ATM  networks,  such  as  switched  virtual  circuits,  specification  of  bandwidth, 
and  QoS  guarantees.  These  services  are  not  available  in  today's  Ethernet  or  Token-Ring 
environments.  If  new  ATM  applications  are  not  developed,  users  will  have  little  or  no 
incentive  to  install  ATM  NICs  in  their  desktops.  Instead,  they  may  upgrade  their  network 
to  Switched  Ethernet  technology,  connecting  to  ATM  backbones  to  meet  their  b^dwidth 
needs.  (Harford,  J.,  p.  19) 

Though  there  is  a  lack  of  API  standards,  many  leading-edge  ATM  vendors  are 
shipping  or  planning  APIs  that  allow  access  to  the  ATM  protocol  stack.  However,  the 
APIs  are  all  diflferent.  As  a  result,  application  writers  must  tailor  an  application  to  a 
specific  ATM  vendor's  NIC.  This  may  cause  application  writers  to  avoid  ATM,  thus 
relegating  the  technology  to  the  backbone.  Also,  the  use  of  vendor-specific  APIs  create 
interoperability  problems,  and  forces  the  user  to  one  vendor  or  a  group  of  allianced 
vendors. 


2.  Projected  Release  of  API  Standards 

Recognizing  the  need  for  an  ATM  API,  the  ATM  Forum  chartered  a  working 
group  to  address  this  challenge.  The  group  is  currently  defining  a  semantic  (not  syntax) 
specification  of  such  an  API.  The  semantic  specification  will  provide  det^s  of  the 
interface  between  an  application  and  the  underlying  ATM  protocol  stack,  but  will  leave 
room  for  difierent  syntaxes  to  account  for  the  operating  environment  and  language 
bindings.  For  example,  an  application  written  in  C  for  a  UNIX  environment  might  require 


43 


porting  to  an  object-oriented  workplace  OS,  but  the  porting  would  be  simplified  because 
the  underlying  ATM  protocol  implements  the  same  services  in  both  environments. 
(Harford,  I,  p.  19) 

The  specifications  the  API  working  group  is  developing  will  not  only  be  designed 
for  portability,  but  also  for  multivendor  interoperability. 

It  is  projected  that  the  ATM  API  specifications  will  be  completed  in  late  1995. 
However,  vendor  implementation  is  not  expected  until  spring  or  summer  or  1996. 

H.  FIREWALLS 

1.  Overview 

An  unresolved  issue  related  to  public  ATM  networks  is  the  use  of  firewalls.  A 
firewall  is  a  combination  of  software  and  hardware  used  to  keep  unauthorized  individuals 
from  accessing  a  private  LAN.  (Buerger,  D.  J.,  p.  79)  The  firewalls  normally  run  on  a 
dedicated  workstation  external  to  the  LAN,  but  inside  the  router  link  to  the  internet.  As 
an  illustration,  a  firewall  may  allow  FTP  access  from  a  public  network  to  a  private 
network.  This  same  firewall  may  prohibit  Telnet  access. 

Firewall  components  normally  consist  of  one  or  more  of  the  three  techniques; 
packet  filtering,  application  gateways,  and  circuit  gateways.  A  brief  description  of  each 
technique  is  provided  below  (Buerger,  D.  I.,  p.  79). 

♦  Packet  filtering  is  usually  performed  by  a  router  as  data  packets  pass  through 
the  router's  interfaces.  The  filter  reads  fields  in  Internet  Protocol  (IP)  packets 
such  as  source  and  destination  IP  addresses  and  TCP/User  Datagram  Protocol 
source  and  destination  ports.  By  checking  these  fields,  the  packet  filter  can 
allow  passage  of  trusted  packets,  or  disallow  passage  of  packets  from 
unauthorized  sources. 

♦  Application  gateways  are  proxy  servers  that  fuimel  approved  users  to  the 
appropriate  application  server.  For  example,  inbound  Internet  users  who  want 
to  use  a  corporate  E-mail,  FTP,  or  WWW  server  could  access  those  services 
only  after  authentication  by  proxy  servers  located  outside  the  corporate  LAN. 


44 


♦  A  circuit-level  gateway  relays  TCP  connections  between  specific  sources  and 
destinations.  These  gateways  do  no  filtering;  they  simply  pass  bytes  back  and 
forth.  An  example  is  a  Telnet  gateway,  which  would  service  the  Telnet  session 
once  the  gateway  permits  its  establishment. 

2.  Problem 

Many  networking  experts  are  not  sure  whether  firewalls  can  be  used  in  an  ATM 
environment.  The  main  problem  is  that  once  an  ATM  connection  is  established,  no 
intermediate  devices  generally  interpret  or  process  any  of  the  information  traversing  the 
connection.  Once  a  connection  is  established  between  two  end  nodes,  any  data  could  be 
sent  down  the  connection  without  visibility  to  network  administration.  While  firewalls,  or 
other  security  devices,  could  be  implemented  in  the  end  systems,  it  is  not  likely  to  be  a 
practical  solution  for  most  end  units.  (Alles,  A.,  1995,  p.  23) 

Many  proposals  have  been  written  recommending  that  firewalls  be  used  at 
connection  set-up  time  instead  of  on  the  transmitted  data.  Special  information  elements 
would  be  defined  within  the  signaling  message  to  indicate  the  type  of  access  (specific 
application,  Telnet,  FTP,  etc.)  is  required.  The  intermediate  switches  would  then  filter  the 
connection  set-up  based  on  the  information  element,  source  and  destination  addresses,  etc. 

Another  approach  to  tackling  the  firewall  issue  is  the  use  of  ATM  address  filtering. 
Address  filtering  could  be  used  at  private,  public,  and  shared  WAN  network  points  to  only 
allow  connectivity  between  trusted  addresses,  and  prevent  general  connections. 

3.  Projected  Resolution  of  Firewall  Issues 

Though  the  two  aforementioned  recommendations  may  have  some  utility,  they  are 
limited  by  the  fact  that  little  prevents  an  end  system  from  lying  about  the  use  to  which  a 
connection  would  be  used,  since  ATM  connections  generally  terminate  at  lower  levels 
within  end  system  protocol  stacks,  and  not  at  the  actual  applications.  As  a  result,  once  a 
connection  is  set  up,  a  node  could  send  packets  of  any  protocol  type  down  the  connection, 
and  have  these  demultiplexed  at  the  destination  to  any  supported  application,  regardless  of 
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the  identity  of  the  application  to  which  the  connection  was  set  up  to.  (Alles,  A.,  1995,  p. 
23) 

Cryptographic  based  authentication  mechanisms  is  a  feasible  solution  to  tackle  this 
problem.  These  mechanisms  can  be  added  to  the  ATM  signaling. 

The  ATM  Forum  has  begun  preliminary  work  on  using  security  mechanisms. 
However,  it  will  be  some  time  before  complete  specification  are  released.  In  the 
meantime,  network  administrators  continue  to  use  routers  as  security  walls.  Some  routers 
are  even  used  to  connect  two  ATM  switches  to  each  other.  Though  this  type  of  set  up 
affects  performance  and  service,  many  network  administrators  prefer  this  type  of  solution 
to  not  having  any  firewall  protection. 

1.  CHAPTER  SUMMARY 

Though  ATM  has  tremendous  capabilities  and  bandwidth  power,  many 
implementation  issues  must  be  addressed,  and  standards  must  be  released  addressing  these 
issues.  This  chapter  discussed  several  of  the  implementation  issues,  such  as  LAN 
Emulation,  network  management,  signaling,  congestion  and  flow  control,  IP  over  ATM, 
APIs,  and  firewalls.  Failure  to  address  these  issues  leads  to  compatibility  and 
interoperability  problems.  To  circumvent  these  problems,  one  would  have  to  buy 
proprietary  products  and  lock  himself  or  herself  into  one  vendor.  This  would  place  the 
organization  at  a  tremendous  disadvantage  should  the  vendor  discontinue  manufacturing 
ATM  products. 

Another  key  point  to  remember  is  that  if  the  future  specifications  addressing  the 
implementation  issues  are  not  clear  and  precise,  vendors  will  implement  the  specifications 
using  various  interpretations.  This  too  could  lead  to  interoperability  problems.  To  avoid 
this  problem,  the  specifications  must  be  clear. 

Several  issues  were  addressed  in  the  previous  sections.  However,  there  are  many 
more  issues  which  the  ITU,  ATM  Forum,  and  applicable  standards  making  bodies  must 
address.  One  in  particular  is  the  fi'ame  relay,  and  cell  relay  compatibility  problem. 
Though  the  Frame  Relay  Forum  and  the  ATM  Forum  agreed  on  how  frame  relay  and 
ATM  interoperates,  the  agreement  is  rudimentary  and  needs  additional  work.  The 
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specification  falls  short  of  full  interoperability  because  it  does  not  address  transfer  between 
a  generic  ATM  interface,  and  a  generic  frame  relay  interface.  Without  this  kind  of 
base-level  interoperability,  the  device  on  the  ATM  network  must  know  that  it  is 
communicating  with  a  frame  relay  device,  and  it  must  treat  that  device  differently  than  it 
would  another  ATM  device.  It  must  run  frame  relay  software,  which  means  running  two 
protocol  stacks  at  the  upper  layer.  This  makes  administration  difficult,  and  can  be  costly 
in  terms  of  processing  power  and  resources.  (Taylor,  S.,  1993,  p.  23) 

Another  implementation  issue  is  voice  over  ATM.  Though  ATM  has  been 
"preached"  about  its  ability  to  send  data,  \ddeo,  and  voice,  the  ATM  primary  focus  has 
been  data  and  video.  The  ATM  Forum  recently  started  a  new  work  effort  to  study  how 
voice  can  be  carried  efficiently  by  ATM,  and  a  new  ATM  adaption  layer  (voice  AAL)  is 
being  discussed.  (Harford,  Jim,  "ATM  must  Make  Way  for  Voice,"  p.  33) 

The  final  implementation  issue  that  will  be  mentioned  is  cell  efficiency  (control 
characters,  and  information  characters).  Approximately  10%  (5  bytes)  of  the  53  bytes  of 
an  ATM  cell  are  dedicated  to  the  header  of  the  cell,  and  the  remaining  90%  (48  bytes) 
carry  information.  When  comparing  this  information  to  Ethernet  packets,  usage  of  the 
ATM  cell  format  is  very  inefficient.  An  Ethernet  packet  size  ranges  from  26  bytes  to 
1,526  bytes.  There  are  26  control  bytes  in  an  Ethernet  packet.  This  equates  to 
approximately  0.017%  of  the  total  1,526  bytes  in  a  full  packet  being  used  as  control 
characters. 
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IV.  ASSESSMENT  OF  SYSTEMS  MANAGEMENT’S  LAB  LAN 


A.  INTRODUCTION 

1.  Purpose  of  Chapter 

The  purpose  of  this  chapter  is  to  provide  a  general  overview  of  the  SM 
Department  computer  lab  LAN.  This  chapter  is  not  intended  to  discuss  the  intricate 
details  of  the  network  topologies  of  the  LAN  and  how  the  various  topologies  function. 
Instead,  the  chapter  will  provide  a  macro-picture  of  how  the  computer  labs  are  physically 
and  logically  connected,  the  types  of  topologies  used,  and  the  hardware  and  software  used 
on  the  network. 

The  SM  Department  computer  lab  network  has  been  in  transition  for  the  past  year. 
While  this  thesis  was  being  written,  PC  LAN  was  installed  on  the  network.  Since  then,  the 
computer  lab  network  has  been  upgraded  to  Windows  for  Workgroup  (WFW).  This 
upgrade  is  not  included  in  the  baseline  assessment. 

2.  General  Overview 

The  SM  Department  of  the  Naval  Postgraduate  School  has  three  microcomputer 
labs  which  are  located  in  Ingersoll  Hall,  rooms  IN-158,  IN-224,  IN-250.  The  labs  in 
IN-224  and  IN-250  are  used  as  instructional  labs;  IN-158  is  used  for  research.  Only  Naval 
Postgraduate  School  students,  faculty,  and  staff  are  authorized  to  use  the  labs. 

A  Token-Ring  network  interconnect  the  three  labs,  providing  connectivity  to  two 
instructor  computers,  41  user  computers,  ten  servers,  and  an  assortment  of  ancillary 
components. 

In  addition  to  the  Token-Ring  network,  the  SM  Department  also  operates  a  3Com 
10  Mbps  Ethernet  LAN,  a  230.4  Kbps  AppleTalk  LAN,  and  a  PCLAN.  The  following 
sections  provide  detail  information  on  these  various  networks. 
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B.  TOKEN-RING  LAN 


The  Token-Ring  network  conforms  to  the  IEEE  802.5  standard  and  operates  at  16 
Mbps.  The  network  establishes  a  ring  topology  using  multi-station  access  units  (MAUs) 
and  shielded-twisted  pair  cabling.  A  depiction  of  the  ring  is  provided  in  Figure  4-1.  To 
better  manage  to  network,  the  network  has  been  segmented  into  three  sections  (OTR, 
4TR,  and  8TR).  These  alpha-numerical  designations  correspond  to  rooms  IN-250, 
IN-224,  and  IN- 15  8,  respectively. 


1.  Topology 

The  Token-Ring  network  uses  a  logical  ring  topology.  Tokens  and  messages  pass, 
uni-directionally,  from  station  to  station,  with  each  station  acting  as  a  repeater.  This  type 

of  network  uses  a  token-passing  scheme  for  network  access.  In  order  for  a  node  to 
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transmit  data,  it  first  must  gain  control  of  the  token.  The  token  is  a  specific  bit  sequence 
that  circulate  amongst  the  nodes.  Once  a  node  possesses  the  token,  it  can  transmit  a 
message  that  is  in  its  output  bufifer. 

To  allow  messages  to  be  routed  to  a  particular  node  or  a  group  of  workstations,  an 
Internet  Protocol  address  is  assigned  to  each  station.  Communication  is  established  and 
maintained  using  PC  LAN  version  1.21  software. 

Though  Token-Ring  is  based  on  a  logical  ring  topology,  the  computers  are 
actually  coimected  to  MAUs  using  a  physical  star  topology.  A  MAU  serves  as  a 
multi-port  hub  connecting  up  to  eight  computers.  The  MAU  routes  messages  between  the 
stations  to  maintain  the  logical  ring,  while  providing  individual  physical  connectivity  to 
each  station. 

MAUs  also  contain  two  ports  to  connect  to  other  MAUs.  These  ports  are 
designated  as  Ring  In  (RI)  and  Ring  Out  (RO).  Figure  4. 1  illustrates  how  OTR,  4TR,  and 
8TR  are  interconnected  using  the  RI  and  RO  ports  of  the  eight  MAUs  which  makeup  the 
SM  Lab  Token-Ring  LAN. 

To  reduce  crosstalk  and  noise,  shielded  twisted  pair  (STP)  cabling  is  used  to 
connect  the  MAUs  and  the  computers.  Network  Interface  Cards  (NICs)  or  network 
adapters  are  installed  in  each  computer  to  allow  connectivity  to  the  computers. 

2.  Configuration 

0.  Instructor  and  User  Computers 

The  instructor  and  user  computers  are  486/33  DX  computers.  Each 
machine  is  equipped  with  a  regular  suite  of  input/output  devices  such  as  keyboard, 
monitor,  mouse,  and  dual  floppy  drives  (3.5  and  5.25  inch).  Several  computers  are 
equipped  with  additional  peripherals  such  as  modems,  CD-ROMs,  projectors,  and 
scanners.  Some  computers  also  have  3270  emulation  capability. 

Each  computer  has  a  CONFIG.SYS  and  an  AUTOEXEC.BAT  file  in  its 
root  directory.  The  CONFIG.SYS  file  customizes  DOS  while  it  is  being  loaded  into 
memory  during  the  boot  process  and  loads  the  various  device  drivers  to  establish  a  logical 
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between  the  device  and  the  entire  system.  After  DOS  has  been  loaded  into  memory,  the 
AUTOEXEC.BAT  file  is  run.  This  file  sets  paths  to  the  logical  or  physical  disk  drives  and 
directories,  loads  specific  operating  files  (when  needed),  and  establishes  environmental 
variables,  as  required.  The  AUTOEXEC.BAT  file  also  sets  parameters  to  display  the 
current  directory  at  the  DOS  prompt,  and  displays  a  standard  screen.  The  screen  display 
could  either  be  a  DOS  prompt  to  load  Windows  or  instructions  to  log  into  the  network. 

The  CONFIG.SYS  and  AUTOEXEC.BAT  files  are  executed  each  time  the 
computer  is  "booted."  Their  executions  are  automatic  and  transparent  to  the  user. 

Besides  the  CONFIG.SYS  and  AUTOEXEC.BAT  files,  other  batch  files 
are  used  to  allow  the  user  quick  and  easy  access  to  various  applications  on  the  network. 
These  applications  may  be  located  on  different  servers.  When  the  user  exits  the 
application,  the  batch  file  executes  additional  DOS  commands  to  return  the  computer  to 
the  standard  network  configuration. 

b.  Servers 

The  Token-Ring  network  currently  operates  ten  servers:  eight  486  DX  33 
MHz  computers  and  two  pentium  computers.  The  location  of  the  servers  is  shown  in 
Figure  4.1,  page  51. 

IN-224  contains  four  of  the  servers.  Two  servers  function  as  files  servers, 
one  doubling  as  a  print  server.  The  other  two  servers  provide  gateway  access  to  the 
mainfi-ame  computer  in  the  Church  Computer  Center  (Ingersoll  Hall).  Nine  of  the  user 
computers  in  IN-224  are  configured  with  3270  emulation  software  to  access  the 
mainfi-ame  computer  via  the  Gateway  servers.  As  a  last  note,  all  of  the  user  computers  in 
IN-224  operate  as  DOS-based  machines  and  runs  only  DOS  applications. 

The  user  computers  in  IN-250,  the  OTR  segment  of  the  Token-Ring 
network,  can  run  either  DOS-  or  Windows-based  applications.  These  computers  access 
the  Pentium  servers  in  IN- 158  to  run  applications.  One  of  the  three  486  DX  33  MHz 
servers  provide  print  services  to  the  users  in  IN-250.  The  remaining  two  servers  provide 
no  services. 
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Finally,  the  486  server  in  IN- 15  8,  the  8TR  segment  of  the  Token-Ring 
network,  provides  file  and  print  services  to  five  user  computers.  Like  the  user  computers 
in  IN-250,  these  computer  run  DOS-  and  Windows-based  applications. , 

c.  Protocols 

The  Token-Ring  network  not  only  uses  the  IEEE  802.5  protocol.  It  also 
uses  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP),  Terminal  Emulation 
(Telnet)  protocol.  File  Transport  Protocol  (FTP),  and  SIMPC.  These  protocols  provides 
the  following  functions. 

♦  TCP/IP  is  a  set  of  communications  protocols  that  encompasses  media  access, 
packet  transport,  session  communications,  file  transfer,  electronic  mail,  and 
terminal  emulation.  All  network  trafl&c  use  these  protocols  while  traversing  the 
network.  Also,  this  protocol  is  used  to  communicate  with  the  mainfi'ame 
computer  in  the  Church  Computer  Center. 

♦  TELNET  is  a  terminal  emulation  protocol  that  provides  remote 
terminal-connection  services.  This  protocol  can  be  used  to  connect  to  either 
the  computer  center's  mainfi'ame  or  a  workstation. 

♦  FTP  is  used  in  conjunction  with  TCP/IP  to  log  in  to  a  network  or  host,  list 
files  and  directories,  and  transfer  files.  This  can  either  be  done  between  PCs, 
or  a  PC  and  a  mainframe. 

♦  SIMPC  is  a  terminal  emulation  program  used  in  conjunction  with  a  modem. 
This  software  allows  a  PC  to  connect  to  a  mainframe  or  a  workstation  and 
transfer  files  between  a  PC  and  a  mainframe. 

3.  Token-Ring  Segment  4TR  (IN-224) 

This  segment  interconnects  four  servers  (two  gateway  servers,  and  two  file 
servers),  an  instructional  computer,  and  15  user  computers.  Three  IBM  8228  MAUs 
provide  the  interconnectivity.  STP  cabling  is  used  to  connect  the  servers  and  computers 
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to  the  MAUs.  A  STP  cable  run  functions  as  a  link  to  the  campus  backbone.  Figure  4.2, 
on  the  next  page,  depicts  the  connectivity. 

Peripheral  equipment  such  as  a  graphics  scanner,  an  external  CD-ROM  reader,  a 
Hewlett-Packard  DeskJet  500  printer,  and  a  video  projection  system  are  also  located  in 
IN-224.  The  scanner  and  CD-ROM  reader  are  attached  to  user  computers,  and  the 
projector  is  connected  to  the  instructor  computer.  The  printer  is  connected  to  the  server 
designated  as  TN6M. 

The  2400  baud  internal  modems  are  installed  in  the  instructor  computer  (TNI  8) 
and  five  user  computers  (TN20,  TN21,  TN22,  TN24,  and  TN25).  These  modem  are  used 
to  access  the  Computer  Center's  mainframe  and  Sun  Workstations,  or  remote  access  to 
other  networks. 

Nine  computers  (the  instructor  computer  and  eight  user  computers)  have  3270 
emulation  capability.  These  computers  use  the  IBM  3270  User-version  Emulation 
Software  to  connect  to  the  Computer  Center  mainframe  via  the  two  3270  Gateway 
Servers  (TNO  and  TNI).  These  servers  access  the  mainframe  through  an  IBM  3174-lL 
Controller.  Coaxial  cable  is  used. 

4.  Token-Ring  Segment  OTR  (IN-250) 

This  segment  interconnects  three  486  servers,  an  instructor  computer,  and  21  user 
computers.  This  segments  comprises  four  MAUs  which  functions  as  the  central  hubs  for 
up  to  eight  computers.  The  MAUs  are  connected  using  the  RI  and  RO  ports.  Figure  4.3, 
on  page  58,  provides  a  diagram  of  how  the  computers  are  connected  to  OTR. 

Server  N3  functions  as  a  dedicated  Systems  Architect  (a  software  design  tool) 
server.  No  other  services  reside  on  this  server.  Server  N6  provides  no  services,  and 
Server  N1 7  provides  print  services. 

The  computers  on  this  segment  use  WFW,  and  access  DOS-  and  Windows-based 
applications  from  the  Pentium  servers  in  IN- 158. 

The  instructor  computer  (N9)  and  six  user  computers  (NIO  through  N15)  are 
configured  with  9600  baud  internal  modems.  These  modems  allow  access  to  the 
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Computer  Center  mainframe  and  the  Sun  Workstations.  The  modems  also  permit  access 
to  the  Token-Ring  network  from  remote  locations. 


Figure  4.2  Token-Ring  Segment  4TR  (IN-224) 
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=  Modem  installed  (9600  bps) 

*  -  8228  Multistation  Access  Unit 
Note:  This  drawing  shows  the  wiring  scheme  of  the  OTR 
Network;  the  du^ram  is  not  to  scale.  All  conqmter  are 
486/33  systems.  SERVER  N6  is  running  but  not 
provindatg  services. 


Figure  4.3  Token-Ring  Segment  OTR  (IN-250) 


5.  Token-Ring  Segment  8TR  (IN-158) 

IN- 158  is  the  Software  Metrics  Lab.  The  segment  in  this  lab  comprises  two 
Pentium  servers,  one  486  DX  33  MHz  server,  and  five  user  computers.  One  MAU  is 
currently  used  in  this  segment  for  interconnectivity.  A  third  Pentium  server  will  be 
connected  to  this  segment  in  the  near  future.  Figure  4.4,  below,  shows  the  current 
segment  configuration. 

The  Pentium  servers  (PN3  and  PN6)  provide  DOS-  and  Windows-based 
application  services  to  users  in  IN-250.  These  servers  also  run  WFW.  The  486  server 
(TN4)  provides  DOS-  and  Windows-based  application  services  and  print  services  to  user 
computers  in  IN- 15 8.  The  third  Pentium  server  will  be  configured  as  a  Windows  NT 
server  when  it  is  added  to  8TR. 
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3270  emulation  cards  are  installed  in  each  user  computer  for  coaxial  connectivity 
to  the  mainframe  via  an  IBM  controller. 


^  =  Modem  installed  (2400  bps) 

=  3270  Emulation  (ttrect  Connection) 

Note:  This  drawing  shows  the  wiring  sdieme  of  tiie  4TR  Networi^  tiie  diagmm  is  not  to  scale. 

The  Pentium  systems  ran  Windowi  for  Wori:  Group  for  users  in  IN250. 

*  All  computer  are  286  systems  exc^t  PN3  and  PN6  which  are  Pentiums. 

Figure  4.4  Token-Ring  Segment  8TR  (IN-158) 

C.  ETHERNET  LAN 

The  Ethernet  LAN  runs  at  10  Mbps  and  consists  of  a  3Com  Server  and  four  486 
DX  33  MHz  user  computers.  The  server  provides  file  and  print  services.  A  Hewlett 
Packard  DeskJet  500  is  attached  to  the  3Com  Server.  The  server  and  user  computers  are 
individually  connected  in  a  star  arrangement,  using  Thinnet  coaxial  cable,  to  an  eight-port 
Ethernet  Repeater.  A  separate  port,  the  Attachment  Unit  Interface  (AUI)  Port,  is  used  for 
connectivity  to  the  Campus  Backbone.  The  repeater  is  a  centralize  connection  provides 
reliability  and  ease  of  connection  and  disconnection. 

Each  user  computer  runs  TCP/IP  software.  Although  ENET4  is  physically 
connected  to  the  Ethernet  Repeater,  it  is  not  part  of  the  network.  It  does  not  run  the 
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3Com  software.  It  is  configured  for  access  only  to  the  campus  backbone  using  the 
TCP/IP  software. 

Figure  4.5,  on  the  following  page,  depicts  the  Ethernet  LAN. 

D.  APPLETALK  LAN 

The  AppleTalk  network  consists  of  sue  Macintosh  Plus  computers.  One  Macintosh 
Plus  functions  as  the  server.  A  Laser  Writer  is  also  connected  to  the  AppleTalk  network 
to  provide  printing  capabilities.  The  Apple  network  uses  its  own  Apple  protocol.  Another 
unique  feature  of  this  network  is  the  use  of  proprietary  AppleTalk  cables  and  connectors. 
The  network  runs  AppleShare  software  for  file  sharing  and  communications  between  the 
users.  AppleTalk  is  used  for  print  services.  The  AppleTalk  LAN  is  dedicated  to  research, 
and  will  possibly  be  upgraded  to  Ethernet  Standards.  Figure  4.6,  on  the  next  page, 
provides  a  layout  of  the  network. 

AppleTalk  is  a  proprietary  network  standard  and  does  not  conform  to  IEEE 
standards.  The  network  is  baseband  and  functions  in  a  bus  topology.  AppleTalk  can 
function  over  STP,  UTP,  and  fiber  optic  cable.  It  runs  at  a  speed  of  230.4  kilobits  per 
second,  and  uses  an  access  scheme  similar  to  the  Ethernet  Carrier  Sense  Multiple 
Access/Collision  Detection,  or  Carrier  Sense  Multiple  Access/Collision  Avoidance. 
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E.  PCLAN  NETWORK 

The  PCLAN  network  comprises  a  server  and  two  user  computers.  These 
components  are  connected  through  a  translator  (hardware).  This  network  is  a  standalone 
network  and  functions  as  a  test  bed  for  implementing  new  network  hardware  and 
software.  The  server  runs  many  DOS-based  applications. 

F.  CHAPTER  SUMMARY 

This  chapter  provided  an  overview  of  the  SM  Department  computer  lab  network. 
The  labs  use  various  network  protocols  to  support  the  facets  of  LANs  that  to  provide  file 
and  print  services  to  NPS  faculty,  staff,  and  students.  The  servers  provide  either  DOS-  or 
Windows-based  applications  services,  or  both.  The  Token-Ring  LAN  has  two  Gateway 
Servers  for  access  to  the  mainfi-ame  computer,  and  a  dedicated  run  to  the  campus 
backbone.  The  Ethernet  network  also  has  a  dedicated  run  for  access  to  the  campus 
backbone.  Two  LANs  (AppleTalk  and  PCLAN)  functions  as  stand  alone  LANs; 
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V.  APPLICATION  OF  ATM  TECHNOLOGY  TO  LANS 


A.  PURPOSE  OF  CHAPTER 

The  purpose  of  this  chapter  is  to  provide  an  illustration  of  an  implemented  ATM 
network  and  to  design  an  ATM  network  that  could  replace  the  current  lab  network  in  the 
SM  Department.  I  will  discuss  the  Supercomputing  1995  Conference  ATM  network  that 
was  installed  in  the  San  Diego  Convention  Center.  I  assisted  the  coordinators  of  this 
ATM  network  while  on  thesis  travel. 

Though  Supercomputing  1995  ATM  network  supported  powerful  workstations 
and  mainframe  computers  on  site  and  across  the  United  States,  the  first-hand  knowledge 
and  actual  configuration  of  ATM  switches  is  applicable  to  the  design  of  an  ATM  network 
for  the  SM  computer  labs. 

B.  SUPERCOMPUTING  1995  NETWORK 

1.  Overview  of  the  Supercomputing  Conferences 

Supercomputing  conferences  provides  computational  scientists  and  engineers  a 
worldwide  forum  to  showcase  their  research.  The  scientists  and  engineers  transport 
portions  of  their  labs  to  the  conference  site,  or  connect  their  labs  over  high-speed 
networks  to  communicate,  educate,  and  learn  from  one  another.  Presentations  at 
Supercomputing  promote  the  development  of  teams  of  computational  scientists  and 
computer  scientists  for  large-scale  problem  solving.  The  presentations  also  foster 
technology  transfer  between  scientists,  industry,  and  future  researchers.  A  third  advantage 
of  the  conferences  is  the  encouragement  of  collaboration  among  academia,  government 
research  labs,  and  industry. 

Two  key  demonstrations  of  existing  technology  and  future  technology  shown  at 
Supercomputing  1995  was  the  GII  Testbed,  and  the  High  Performance  Computing  (HPC) 
Challenge.  A  summary  of  these  demonstrations  are  provided  below.  (Korab,  H.  and 
Brown,  M.  D.,  1995,  p.  2) 
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a. 


GII  Testbed 


The  GII  Testbed  was  an  interactive  2D  and  3D  scientific  visualization,  and 
virtual  reality  demonstrations  of  research  projects  that  used  high-performance  computing 
and  communications  to  attack  large  scale  problems.  The  applications  were  computed  in 
the  scientists'  numerical  labs,  and  then  transmitted  over  the  I-WAY  (Information  Wide 
Area  Year,  national  scale,  applications-focused,  community-based  ATM  network)  to  the 
Supercomputing  1995  convention  floor.  The  applications  emphasized  distributed, 
real-time  heterogeneous  computing,  large  data  sets,  remote  instrumentation,  collaboration, 
and  advanced  display  devices. 

b.  HPC  Challenge 

The  HPC  Challenge  was  a  forum  for  scientists  who  are  on  the  leading  edge 
to  challenge  the  computational  limit  of  heterogeneous  computing  in  the  race  to  the 
teraflop.  The  goal  of  the  HPC  Challenge  was  to  assemble  the  greatest  amount  of 
computing  power  and  speed  to  run  a  single  scientific  application  on-site  and  over  the 
I-WAY. 

Most  of  the  GII  Testbed  and  the  HPC  Challenge  applications  were  highly 
graphical.  These  applications  were  displayed  in  the  following  advanced  virtual  reality 
environments. 

♦  Cave  Automatic  Virtual  Environment  (CAVE)  -  alOxlOx  9-foot 
room-sized,  multi-person,  high  resolution  3D  video  and  audio  environment. 

♦  ImmersaDesk  -  a  scaled-down  version  of  the  CAVE,  about  the  size  of  a 
drafting  table,  that  brings  3D  virtual  environment  technology  into  the  oflBce. 
The  ImmersaDesk  is  portable  yet  large  enough  to  fill  a  persons  field  of  view 
when  he  or  she  is  seated  in  front  of  it. 

♦  NIIAVall  -  is  a  large  projection  display  created  from  four  1280  x  1024  screens. 
Like  the  ImmersaDesk,  images  appear  on  one  plane  and  can  be  in  stereo. 
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2.  Implementation  of  the  Conference  Network 

The  network  implementors  and  administrators  used  a  variety  of  networking 
technology  to  provide  connectivity  to  the  participants,  both  on  site  and  off  site,  of  the 
Supercomputing  conference.  The  technology  ranged  from  ATM  to  FDDI,  Ethernet,  and 
Switched  Ethernet. 

The  participants  had  access  to  their  research  data  via  the  I-WAY  and  the  internet. 
The  I-WAY,  an  ATM  testbed,  was  an  experimental,  high-performance  and  high-speed 
network  which  linked  dozens  of  the  United  States'  fastest  computer  and  advanced 
visualization  machines.  The  I-WAY  also  provided  the  backbone  for  all  the  high-end 

networking  activities  during  the  conference. 

In  order  for  the  I-WAY  to  be  accessible  in  major  conference  rooms,  selected 
research  and  exhibit  booths,  video  display  kiosk,  and  other  areas  of  the  convention,  the 
I-WAY  was  connected  to  the  WAVE,  the  Wide  Area  Visualization  Experimental.  The 
WAVE  LAN  also  supported  visualization  and  virtual  reality  applications  and  video  server 
technology  within  the  convention  center.  Each  application  in  the  GII  Testbed  and  the 
HPC  Challenge  accessed  the  WAVE  through  both  ATM  and  Ethernet  connectivity. 

A  second  network  which  functioned  on-site  was  the  SCInet.  This  network  was  the 
production  network  which  provided  a  seamless  infrastructure  throughout  the  convention 
center.  The  SCInet  also  provided  external  connectivity  to  the  I-WAY  and  the  internet,  as 
well  as  internal  connectivity  among  the  booths,  meeting  rooms,  electronic  mail-equipped 
rooms  and  kiosks. 

An  illustration  of  the  of  the  SCInet/I-WAY  architecture  overview  is  provided  in 
Figure  5.1  on  the  following  page.  This  figure  provides  a  general  idea  of  how  the  SCInet 
ATM  cloud  (network)  accessed  rooms  and  booths  on-site,  the  I-WAY,  the  internet,  and 
other  sights.  Figure  5.1  also  includes  the  WAVE  ATM  cloud  which  provided  connectivity 
to  Kiosks,  SP2,  and  the  GII  Room. 
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The  SCInet  and  the  WAVE  ATM  fabric  obtained  access  to  the  I-WAY  and  the 
internet  through  the  San  Diego  Convention  Center  (SDCC)  and  the  San  Diego  State 
Supercomputing  (SDSC)  points  of  presence  (POPs). 

CL  Hardware  Configuration 

As  mentioned,  ATM,  FDDI,  Ethernet,  and  Switched  Ethernet  technologies 
were  used  to  provide  network  connectivity  throughout  the  convention  center.  Many 
network  administrators  used  wireless  network  connectivity  to  maintain  the  network. 
Because  this  thesis  focuses  of  ATM  technology,  I  have  omitted  detail  discussions  of  how 
users  and  network  administrators  used  FDDI,  Ethernet,  Switched  Ethernet,  and  Wireless 
network  technologies. 
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Figure  5.2  depicts  the  ATM  switch  fabric  and  physical  connectivity  of  the 
switches.  Four  Fore  BX  and  four  Fore  BXE200  ATM  switches  implemented  the  ATM 
fabric.  The  BXs  supported  one  16-port  card.  The  BXE200s  contained  four  slots  of 
which  each  slot  could  have  functioned  as  a  single  16-port  switch.  As  a  result,  each 
BXE200  was  capable  of  functioning  as  four  separate  switches.  However,  only  two  of  the 
BXE200S  utilized  four  16-port  cards. 


Figure  5.2  ATM  Switch  Fabric 


The  switches  were  connected  using  either  single  mode  (SM)  or  multi-mode 
(MM)  fiber.  The  speed  of  each  fiber  run  ranged  fi-om  155  Mbps  (OC3c)  to  622  Mbps 
(OC12).  As  shown  in  the  above  figure,  the  fiber  run  between  TCG  and  SDSC  was 
capable  of  supporting  throughput  of  up  to  2.4  Gbps  (OC48). 
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The  SODA-CC  BXE  fiinctioned  as  the  central  switch  for  connectivity  to 
other  switches,  routers,  and  users.  The  users  obtained  I-WAY  and  internet  access  through 
the  SODA-CC  BXE.  The  routers  provided  connectivity  to  PDDI,  Switched  Ethernet,  and 
Ethernet  networks  within  the  convention  center.  The  remaining  BXEs  (WAVEl, 
SCINET2,  and  SCINET3)  and  the  BXs  (WAVE2,  WAVES,  WAVE4,  SCINET4) 
provided  connectivity  to  the  convention  floor  (booths,  exhibits,  conference  rooms, 
meeting  rooms,  classrooms,  etc.). 

b.  Software  Configuration 

The  Fore  BXE  and  BX  switches  were  configured  using  software  written 
specifically  for  them.  One  cannot  guarantee  that  the  software  could  run  on  a  Cisco, 
Newbridge,  or  any  other  manufactured  ATM  switch.  However,  the  software  complied 
with  ATM  standards  (UNI  vS.O,  etc.).  By  complying  with  the  standards,  the  Fore 
switches  were  able  to  communicate  with  other  brand  name  switches  which  also  followed 
ATM  standards. 

The  Fore  switches  were  setup  individually  to  ensure  that  they  could 
function  in  a  stand-alone  mode  prior  to  connecting  them  to  form  the  ATM  network.  As 
the  switches  were  connected  physically,  logical  connections  were  formed  to  pass 
information.  These  logical  links  were  created  using  virtual  circuits  (PVCs  or  SVCs).  UNI 
vS.O  or  Fores  proprietary  software  (SPANS)  was  used  to  establish  the  virtual  circuits. 
The  network  administrators  used  UNI  vS.O  for  any  connection  connecting  a  Fore  and  a 
non-Fore  switch  or  device  to  ensure  interoperability.  SPANS  was  used  when  Fore 
switches  or  devices  were  connected. 

3.  Maintenance 

SNMP  (Simple  Network  Management  Protocol)  functioned  as  the  network 
management  application.  This  protocol  ran  under  the  Fores  proprietary  network 
management  graphics  user  interface  (GUI)  tool.  Foreview.  Foreview,  specifically 
designed  for  the  Fore  switches,  allowed  the  network  administrators  to  view  each  switch, 
down  to  the  port  level.  Instead  of  having  to  physically  stand  in  fi'ont  of  the  switch  to 
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determine  the  status  of  each  port,  the  network  administrator  could  determine  the  status  of 
the  port  be  clicking  on  a  graphical  representation  of  the  port  displayed  on  his  workstation. 

Foreview  was  also  used  to  create,  modify,  or  delete  virtual  paths  and  virtual 
channels.  These  paths,  and  channels  were  defined  as  either  permanent  (PVCs)  or 
temporary  (SVCs).  When  the  PVCs  were  created,  the  port  at  the  origin,  destination,  and 
intermediate  ports,  had  to  be  identified.  However,  only  the  IP  address  of  the  origin  and 
destination  had  to  be  identified  when  establishing  a  SVC. 

C.  SYSTEMS  MANAGEMENT'S  COMPUTER  LAB  LAN 

1.  Overview 

Chapter  FV  provided  a  general  overview  of  the  Systems  Management's  three 
microcomputer  labs  which  are  located  in  Ingersoll  Hall,  rooms  IN- 15  8,  IN-224,  and 
IN-250.  The  lab  in  IN-158  is  used  for  research;  whereas,  IN-224  and  IN-250  are  used  for 
instructional  purpose. 

A  Token-Ring  network  interconnects  the  three  labs  providing  connectivity  to  two 
instructor  computers,  40  user  computers,  ten  servers,  and  an  assortment  of  ancillary 
components.  In  addition  to  the  Token-Ring  network,  the  SM  Department  operates  a 
3Com  10  Mbps  Ethernet  LAN,  a  230.4  Kbps  AppleTalk  LAN,  and  a  PCLAN.  The  3Com 
LAN  is  located  in  IN-224,  and  the  AppleTalk  LAN  and  PCLAN  functions  in  IN-158. 

ATM  technology  will  now  be  used  to  redesign  the  Token-Ring  and  Ethernet  LANs 
into  one  integrated  LAN.  The  redesign  is  based  on  the  PC  LAN  which  was  installed  when 
this  thesis  was  written.  However,  the  redesign  can  easily  adopt  the  upgraded  PC  LAN,  a 
WFW  configured  network. 

To  redesign  the  LANs,  physical  and  logical  topologies,  as  well  as  the  hardware 
and  software  configurations  must  be  addressed.  For  simplicity,  the  hardware  configuration 
will  include  the  physical  topology,  and  the  software  configuration  will  include  the  logical 
topology. 
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2. 


Hardware  Configuration 


a.  ATMLAN 

The  ATM  network,  being  designed,  will  conform  to  the  ATM25  and 
ATM155  standards.  The  ATM  Forum's  Physical  Layer  Working  Group  voted  to  adopt 
25.6  Mbps  specification  (the  ATM25  standard)  as  the  baseline  for  a  medium-speed  ATM 
physical  connection  specification  (Duffy,  C.  A.,  1995,  p.  1).  The  new  specification  will 
allow  the  use  of  Category  3  UTP  cable,  and  full-duplex  25.6  Mbps  connectivity.  This  type 
of  connectivity  equates  to  approximately  50  Mbps  throughput  capability. 

Not  only  can  ATM25  standard  function  over  UTP,  it  can  also  run  over 
STP,  coax,  and  fiber.  However,  most  vendors  are  manufacturing  ATM25  switches  which 
connect  PCs  using  UTP.  STP,  coax,  or  fiber  is  used  to  connect  switches  over  long 
distances,  or  distances  that  exceed  UTP  limitations,  and  to  obtain  higher  throughput. 

The  ATM  155  Mbps  standard  has  been  in  existence  for  some  time. 
Typically,  fiber  has  been  used  to  support  this  throughput  rate.  However,  STP  and 
Category  5  UTP  are  considered  as  viable  and  cheaper  alternatives  to  fiber.  Vendors  are 
now  producing  ATM155  NICs  which  support  STP  and  Category  5  UTP. 

Figure  5.3,  on  the  following  page,  depicts  the  redesigned  network.  The 
network  has  six  segments  (OATM,  4ATM,  8ATM,  4EN,  4TR,  and  8TR).  The  first 
number  of  each  alpha-numerical  designation,  0,  4,  and  8,  correspond  to  rooms  IN-250, 
IN-224,  and  IN- 158,  respectively. 
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Segments  4TR  and  8TR  (48TR)  are  interconnected  to  form  a  small 
Token-Ring  that  consist  of  nine  computers.  Three  of  the  computers  are  located  in 
IN-224;  five  computers  are  in  IN-158.  All  of  these  clients  will  have  access  to  the 
Pentiums  servers  in  IN-158. 

The  proposed  network  consists  of  five  ATM  switches  and  an  ATM  LAN 
Bridge.  Of  the  five  switches,  four  are  ATM25  switches  (stacked  in  groups  of  two)  and 
one  is  an  ATM155  switch.  The  ATM  LAN  Bridge  functions  as  a  bridge  to  allow  ATM, 
Token-Ring,  and  Ethernet  technologies  to  operate  in  one  integrated  network. 

Each  ATM25  switch  is  capable  of  supporting  up  to  12  computers.  Most 
vendors  are  designing  ATM25  switches  with  12  desktop  ports.  However,  these  switches 
are  stackable  using  a  Stacking  Bus. 
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Because  of  the  number  of  computers  (user  computers  and  servers)  that  will 
be  upgraded  to  ATM,  two  or  more  stacked  switches  are  necessary  for  IN-224  and 
IN-250.  Figure  5.3  depicts  only  two  stacked  switches  for  IN-224  and  IN-250.  However, 
the  number  of  stacked  switches  can  be  increased  easily. 

Only  one  switch,  an  ATM155  switch,  is  necessary  in  IN-158.  This  switch 
will  provide  connectivity  to  the  servers,  the  ATM25  switches  in  IN-224  and  IN-250,  and 
the  ATM  LAN  Bridge. 

The  155  Mbps  ATM  switch  in  IN-158  will  provide  high  speed  access  to 
the  servers  and  the  switches  in  IN-224  and  IN-250.  This  configuration  will  greatly 
enhance  the  throughput  capability  of  the  integrated  network,  particularly  under  the  new 
WFW  network  configuration.  In  the  WFW  network  configuration,  the  applications  (DOS- 
and  Windows-based)  will  reside  on  the  Pentium  servers  (PN3  and  PN6)  in  IN-158.  The 
155  Mbps  connections  to  these  servers  will  provide  the  users  faster  response  time. 

Currently,  Type  1  STP  cable  is  in  place  to  connect  computers  to  the 
Token-Ring  network.  ATM25  is  compatible  with  Type  1  STP  cable,  but  most  vendors 
are  designing  their  switches  to  support  UTP  or  Ethernet  lOBaseT  cable.  IBM  may  be 
designing  switches  which  are  compatible  Avith  Type  1  STP  cable.  Should  switches  which 
are  compatible  with  Type  1  cable  be  used,  additional  Type  1  cable  may  be  required.  In  the 
current  Token-Ring  LAN,  the  T)q)e  1  cable  connects  the  computers  to  the  appropriate 
MAU,  and  the  MAUs  are  connected  via  Type  1  cable.  In  the  case  of  ATM,  each  Type  1 
cable  link  must  run  directly  to  a  port  in  the  switch.  The  switches  in  IN-224  and  IN-250 
will  be  stacked,  and  in  a  one  location. 

Another  area  that  requires  addressing  should  Type  1  cable  be  used  is  the 
connectors.  Very  few,  if  any,  switches  have  ports  compatible  with  IBM  Token-Ring 
Adapters.  Instead,  the  switches  are  compatible  with  RJ-45,  coax,  or  fiber  connectors.  In 
order  to  marry  the  Type  1  cable  (DB-9  connectors)  to  the  switch  port,  an  intermediate  or 
connector  conversion  must  occur. 

Figure  5.3  also  shows  the  fiber  connectivity  between  IN-158,  IN-224,  and 
IN-250.  Multi-mode  fiber  is  the  recommended  medium  because  of  the  distance  between 
the  rooms,  possibility  of  noise,  and  the  155  Mbps  throughput.  Many  ATM25  switches 
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are  capable  of  interconnectivity  throughput  of  up  to  155  Mbps.  This  throughput  rate  may 
exceed  the  Systems  Management's  requirement  and  the  capability  of  the  servers  and  PCs. 
However,  the  multi-mode  fiber  supports  this  throughput,  and  allows  room  for  bandwidth 
growth.  As  faster  servers  and  PCs  are  purchased,  the  throughput  capability  will  be 
available  to  accommodate  the  increased  demand  for  more  bandwidth. 

Multi-mode  fiber,  STP,  or  Category  5  UTP  can  be  used  to  connect  the 
servers  and  the  ATM  LAN  Bridge  in  IN-158  to  the  ATM155  Switch  in  IN-158. 

b.  ATM  Segment  4ATM  (IN-224) 

The  redesigned  network  in  IN-224  uses  ATM,  Token-Ring,  and  Ethernet 
technologies.  Because  IN-224  functions  as  the  networks  lab,  the  interconnectivity  of  the 
three  network  technologies  provides  students  and  staff  hands-on  experience  in  an 
integrated  environment. 

In  this  environment,  the  Ethernet  network  (4EN)  will  remain  intact.  The 
only  addition  would  entail  linking  the  repeater  to  the  ATM  LAN  Bridge.  This  attachment 
may  require  the  use  of  one  of  the  repeater  ports.  The  ATM  LAN  Bridge  must  be  capable 
of  supporting  a  coaxial  or  RJ-45  connection.  However,  a  coaxial  cable  is  recommended 
because  of  the  distance  between  the  Repeater  and  the  ATM  LAN  Bridge.  The  bridge  will 
be  located  in  IN-158. 

The  Ethernet  campus  backbone  connection  can  be  disabled  or  remain 
enabled  to  function  as  a  backup  to  the  Token-Ring  campus  backbone  connection  through 
the  Cisco  router.  However,  only  one  backbone  connection  is  needed  on  the  integrated 
network. 

The  Token-Ring  Segment  4TR  is  a  much  smaller  version  of  the  existing 
4TR  segment.  This  redesigned  segment  is  comprised  of  one  MAU  and  three  computers. 
However,  4TR  is  expandable  up  to  six  computers.  One  port  is  required  for  backbone 
connectivity.  A  second  port  is  necessary  to  link  the  MAU  to  the  ATM  LAN  Bridge.  The 
RI  and  RO  ports  are  used  for  connectivity  to  the  MAU  in  IN-158. 

Figure  5.4,  next  page,  depicts  the  4 ATM  Segment.  This  segment  consists 
of  two  ATM25  Switches  for  connectivity  to  a  maximum  of  24  computers.  However,  17 
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of  the  20  computers  are  designated  to  be  upgraded  to  ATM.  This  leaves  seven  ports  that 
are  available  for  growth. 

Figure  5.4  also  shows  two  new  servers  (Novell  Server  PNl  and  Print 
Server)  that  will  be  upgraded  to  ATM.  These  servers  replaced  TN6M  and  TN3  during  the 
WFW  upgrade. 

IN-224  ATM  LAN  (4ATJVID  _ , 


Figure  5.4  IN-224  ATM  LAN  (4ATM) 

The  two  ATM25  switches  that  will  service  the  17  computers  will  be 
stacked  on  top  of  each  other  using  the  Stacking  Bus  Option.  The  Stacking  Bus  Option 
allows  a  group  of  ATM  switches  to  be  stacked  on  top  of  one  another  and  function  as  one 
"combined"  switch. 

Existing  peripheral  equipment  (printers,  a  graphics  scanner,  an  external 

CD-ROM  reader,  a  video  projection  system,  and  internal  modems)  is  included  in  the 
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proposed  designed.  These  peripherals  are  connected  to  the  same  server  or  user  computer 
that  they  are  currently  connected  too  in  the  existing  Token-Ring  and  Ethernet  LANs. 

Computers  that  currently  have  3270  emulation  capability  will  not  loose  this 
capability  in  the  ATM  LAN.  These  computers  will  continue  to  have  the  ability  to  connect 
to  the  Computer  Center  mainframe  via  the  two  3270  Gateway  Servers  (TNO  and  TNI). 
These  servers  will  continue  accessing  the  mainframe  through  an  IBM  3174- IL  Controller. 

c.  ATM  Segment  OATM  (IN-250) 

ATM  Segment  OATM  interconnects  one  486  server,  an  instructor 
computer,  and  22  user  computers.  Two  switches  are  stacked  using  the  Stacking  Bus 
option.  As  with  the  4ATM  segment,  each  computer  requires  a  dedicated  STP  or  UTP 
cable  run.  Figure  5.5,  below,  provides  a  diagram  of  how  the  computers  would  be 
physically  connected  in  the  OATM  segment. 

Unlike  the  original  Token-Ring  Segment  OTR  (IN-250),  Servers  N3,  N6, 
and  N17  are  not  used  in  Segment  OATM.  These  servers  were  not  included  in  the  WFW 
upgrade.  However,  Print  Server  WFWPRT#!  was  apart  of  the  WFW  upgrade.  This 
server  vrill  provide  print  services. 

Each  computer  on  the  OATM  segment  will  use  WFW  and  access  DOS-  and 
Windows-based  applications  from  the  Pentium  servers  in  IN-158.  The  stacked  ATM 
switches  in  IN-250  are  connected  to  the  155  Mbps  ATM  switch  in  IN-158  by  a 
multi-mode  fiber  cables.  The  connection  supports  speeds  up  to  155  Mbps  between  the 
stacked  25  Mbps  switches  in  IN-250  and  the  155  Mbps  switch  in  IN-158. 

The  instructor  computer  (N9)  and  six  user  computers  (NIO  through  N15) 
keep  their  9600  baud  internal  modem  configuration.  As  with  the  current  LAN,  these 
modems  will  aUow  access  to  the  Computer  Center  mainframe  and  the  Sun  Workstations. 
The  modems  will  also  allow  access  to  the  ATM  network  from  remote  locations. 

All  24  desktop  ports  of  the  stacked  ATM  switches  are  designated  for  use. 
Though  the  stacked  switches  are  at  maximum  capacity  (physically),  a  third  ATM25  Switch 
(same  vendor)  can  easily  be  added  to  the  stacked  switches  to  allow  growth  for  12 
additional  computers. 
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25.6  Mbps  AIM 

Switches  (Stacked)  UterNl?  UierNlS  UferN19  U»ctN20  UferN21  U»erN22 


Figure  5.5  IN-250  ATM  LAN  (OATM) 

d  ATM  Segment  8ATM  (IN-158) 

IN-158  is  the  Software  Metrics  Lab.  The  redesigned  integrated  network  in 
this  dedicated  lab  comprises  ATM  and  Token-Ring  technology.  Figure  5.6,  on  the 
following  page,  illustrates  how  the  two  networking  technologies  are  integrated  into  one 
network.  Regarding  the  ATM  technology,  a  155  Mbps  ATM  switch  and  an  ATM  LAN 
Bridge  is  used.  The  high-speed  switch  provides  155  Mbps  connectivity  to  two  Pentium 
Servers,  the  Stacked  ATM25  Switches  in  IN-224  and  IN-250,  and  the  ATM  LAN  Bridge. 
The  Pentium  Servers,  and  the  ATM  LAN  Bridge  can  be  connected  to  the  high-speed 
switch  using  either  multi-mode  fiber,  STP,  or  Category  5  UTP  cable.  Vendors  claim  the 
Category  5  UTP  cable  supports  155  Mbps  throughput  rates.  However,  very  few  network 
administrators  used  this  type  of  cable  when  upgrading  to  155  Mbps  ATM  LANs.  To 


reduce  risks  of  implementing  new  technology,  Category  5  UTP  should  not  be  considered 
as  an  alternative. 


Figure  5.6  IN-158  ATM  LAN  (8ATM) 

The  ATM  LAN  Bridge  provides  connectivity  to  the  ATM,  Token-Ring, 


and  Ethernet  segments  of  the  integrated  network.  This  connectivity  will  allow  the 
computers  in  the  various  segments  to  communicate  and  share  resources  though  they  may 
use  different  networking  protocols. 

The  Pentium  servers  (PN3  and  PN6)  will  continue  providing  DOS-  and 
Windows-based  application  services  to  users  in  IN-250.  These  servers  will  also  continue 
running  WFW.  As  additional  pentium  servers  are  added  to  the  network,  they  should  be 
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connected  to  the  high-speed  switch  on  Segment  8ATM.  This  will  provide  faster  response 
time  to  the  users. 

The  486  server  (TN4)  and  the  five  Token-Ring  computer  will  remain  on 
Segment  8TR.  One  MAU  is  adequate  to  provide  connection  to  the  six  computers.  One 
port  on  the  MAU  will  be  used  to  link  Segment  8TR  to  the  ATM  LAN  Bridge.  Server 
TN4  can  continue  providing  DOS-  and  Windows-based  application  services  and  print 
services  to  user  computers  in  IN- 15 8.  However,  as  faster  servers  are  connected  to  the 
ATM155  switches,  the  applications  and  print  services  can  be  transferred  to  the  faster 
servers,  thus  providing  faster  and  better  services  to  Software  Metrics  Lab  users. 

The  AppleTalk  LAN  and  the  PCLAN  were  not  included  in  the  integrated 
network  in  IN-158.  Because  the  AppleTalk  LAN  and  the  PCLAN  are  proprietary  and  are 
in  compliance  with  the  IEEE  802  standards,  very  few  vendors  are  producing  products  that 
are  interoperable  with  these  LAN  protocols.  As  a  result,  I  recommend  that  these  LANs 
remain  separate,  and  not  be  incorporated  in  the  integrated  network.  If  the  LANs  were 
included,  the  integrated  network  may  become  proprietary  itself 

e.  Hardware  Requirement 

Based  on  the  physical  design  of  the  SM  Lab  ATM  LAN,  the  hardware 
requirements  to  implement  the  LAN^are  provided  in  the  table  on  the  following  page.  The 
table  provides  the  items,  quantity,  and  special  comments. 

As  mentioned  in  the  previous  sub-section,  UTP,  STP,  or  Type  1  cabling,  or 
a  combination  of  these  cable  types  can  be  used  to  connect  the  computers  to  the  switches. 
However,  for  consistency  and  a  more  homogeneous  network,  it  is  better  to  use  one  type 
of  cabling,  either  UTP  or  STP,  to  provide  connectivity  to  each  computer  (server, 
instructor  and  user  computers)  connected  to  the  ATM25  switches.  Multi-mode  fiber,  or 
STP  should  be  used  for  ATM25  Switch  -  ATM155  Switch,  ATM155  Switch  -  ATM  LAN 
Bridge,  and  ATM155  -  Pentium  Server  links.  Fiber  and  STP  support  the  155  Mbps 
throughput  rate  better  than  UTP. 
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Type  1  cabling  is  a  possible  option,  particularly  since  this  type  of  cable  is 
currently  in  place,  but  few  vendors  are  manufacturing  NICs  which  are  compatible  with  this 
cable  (DB-9  connector).  Also,  additional  Type  1  cable  and  connectors  are  required  to 
extend  the  cable  runs  from  each  computer  to  the  centralized  switches  (stacked). 


Item 

Comments 

ATM155  Switch 

12  Port  ATM25  Switch 

1 

Most  ATM25  Switches  are  configured  with  12  ports. 
If  an  ATM25  Switch  is  configured  with  16  ports, 
four  switches  are  still  needed. 

ATM  LAN  Bridge 

1 

Should  support  Token-Ring  and  Ethernet 
Connections 

Stacking  Bus  Option 

2 

For  Switches  in  IN-224  and  IN-250. 

155  Mbps  Line  Interface  Cards 

9 

6  for  ATM155  Switch. 

2  -  one  each  for  the  ATM25  Switch 

1  for  the  ATM  LAN  Bridge 

25.6  Mbps  Line  Interface  Cards 

0 

Typically,  the  ATM25  Switches  require  no  Line 
Interface  Cards  for  connection  to  computers. 
Instead,  these  switches  are  shipped  with  RJ-45  ports 
which  are  ready  for  connectivity.  However,  if  there 
are  requirements  for  specific  configurations  (certain 
cable  or  coimectors),  the  ATM25  Switch  may  require 
41  Line  Interfece  Cards. 

25.6  Mbps  Network  Interface  Card 

41 

For  Computers  designated  for  connection  to  the 
ATM25  Switches. 

UTP  or  STP  Cabling 

■1 

If  all  cabling  replaced. 

Type  1  (STP)  Cabling 

■ 

If  existing  Type  Cable  is  used. 

Coax 

Backbone  Connectivity 

Multi-mode  Fiber  Cable 

Switch-Switch  and  Pentium  Server  -  Switch  Links 

Connectors 

" 

UTP,  STP,  Type  1 

Coax 

2 

Backbone  Cormectivity 

Multi-mode  Fiber 

12 

Switch-Switch  ,  Pentium  Server-Switch,  and  ATM 
LAN  Bridge-Switch  Links 

Table  5. 1  ATM  Hardware  Requirements 


Regardless  of  the  type  of  cabling  that  would  be  used  to  provide 
connectivity,  the  appropriate  NICs  must  be  installed  in  the  each  computer.  ISA  or  EISA 
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NICs  are  necessary  for  the  486  DX  33  MHz  computers.  The  Pentium  computers  can  use 
PCI  configured  NICs. 

3.  Software  Configuration 

a.  Server  and  User  Computer  Configuration 

In  order  for  ATM  technology  to  function  properly  with  any  network,  some 
form  of  change  in  the  software  configuration  must  occur  in  network  servers  and  the  user 
computers.  Generally,  these  changes  may  encompass  the  replacement,  upgrade,  or 
modification  of  current  network  drivers  (Token-Ring,  Ethernet,  etc.).  These  drivers  are 
loaded  into  memory  during  the  boot  process  to  establish  a  logical  connection  between  the 
computer  and  the  entire  system.  The  CONFIG.SYS  file  in  the  user  and  instructor 
computers  contains  the  drivers.  The  servers  also  have  a  special  file  that  is  executed  every 
time  they  are  booted  to  create  a  network  environment  (Token-Ring,  Ethernet,  etc.)  after 
loading  appropriate  network  drivers  into  memory. 

The  NIC  drivers  for  the  PCs  and  the  servers  must  be  compatible  with  the 
network  operating  system  (NOS).  This  is  also  true  with  ATM  network  drivers.  Many 
vendors  are  currently  manufacturing  ATM  NIC  drivers  that  function  with  WFW, 
Windows  NT,  and  Netware.  In  some  cases,  the  ATM  drivers  will  not  be  compatible  with 
all  three.  Therefore,  if  an  office  has  a  network  which  has  all  three  of  the  these  networks, 
different  NICs  from  different  vendors  may  be  required.  If  so,  this  may  lead  to 
compatibility  problems  between  the  cards  and  the  ATM  switches  if  the  vendors  do  not 
adhere  to  the  ATM  Forum  standards. 

b.  Switch  Configuration 

Not  only  must  appropriate  network  drivers  be  used  to  ensure  a  functioning 
ATM  network;  the  ATM  switches  must  also  be  configured  properly.  The  switches  must 
be  configured  to  run  as  an  IP  network  or  a  network  using  LAN  Emulation.  In  the  case  of 
the  SM  Lab  LAN,  LAN  Emulation  should  be  used.  The  LAN  Emulation  protocol  defines 
the  mechanisms  to  emulate  either  an  IEEE  802.3  Ethernet  or  an  802.5  Token-Ring  LAN. 
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As  discussed  in  Chapter  II,  the  LANE  protocol  defines  the  operation  of  a 
single  emulated  system  LAN  (ELAN).  Multiple  ELANs  may  coexist  simultaneously  on  a 
single  ATM  network  since  ATM  connections  do  not  collide.  A  single  ELAN  emulates 
either  Ethernet  or  Token-Ring  and  must  consist  of  LECs,  a  LES,  BUS,  and  LEGS. 
Chapter  H,  Section  C.3  provided  a  detail  description  and  function  of  these  components. 

Based  on  the  configuration  of  the  SM  Department  Lab  Network  when  this 
thesis  was  written,  and  the  proposed  design  of  the  SM  Department  Lab  Integrated 
Network,  four  ELANs  are  recommended.  The  former  OTR  Segment,  the  new  OATM 
Segment,  encompasses  ELAN#1.  ELAN#2  (IN-224)  comprises  of  the  smaller  4TR 
Segment,  and  the  computers  that  are  upgraded  to  ATM  (Segment  4ATM).  The  Ethernet 
LAN  (4EN)  in  IN-224  is  ELAN#3.  This  LAN  will  remain  intact  and  be  connected  to  the 
ATM  LAN  Bridge.  ELAN#4  includes  a  smaller  8TR  Segment  of  the  Token-Ring 
Network.  The  Pentium  Servers  will  be  a  member  of  each  ELAN  because  they  provide 
application  services  to  each  ELAN.  The  ATM  switches  in  the  various  ELANs  will 
fimction  as  the  LES(s),  BUS(s),  and  LECS(s).  Figure  5.7,  on  the  next  page,  shows  an 
illustration  of  the  ELANs. 

Not  only  must  the  ATM  Switches  support  LAN  Emulation,  the  ATM  LAN 
Bridge  must  also  support  LAN  Emulation.  Without  this  capability,  the  bridge  will  be 
unable  to  forward  information  to  the  correct  ELAN  or  user. 

Appendix  B  provides  information  on  LAN  Emulation  products  (Hold,  D. 

F.,  1995,  p.l). 
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SM  Department  Emulation  LANs  (ELANs) 


Figure  5.7  Systems  Management  Emulated  LANs 


c.  Virtual  Connectivity 

Chapter  n  also  discussed  PVC  (Permanent  Virtual  Circuit)  and  Switched 
Virtual  Circuit  (SVC)  connections.  PVCs  are  permanent  or  dedicated  connections. 
Whereas,  SVCs  are  established  for  information  transmissions  and  tomdown  after  all 
information  has  reached  the  receiving  end. 

In  the  case  of  the  Systems  Management  Lab  ATM  LAN,  PVCs  should  be 
used  for  connectivity  to  and  from  the  servers  and  switch-to-switch  connectivity.  The  PVC 
(full-duplex)  throughput  should  be  25.6  Mbps  and  155  Mbps,  each  way,  for  server  and 
switch-to-switch  connectivity,  respectively.  The  Pentium  Servers  connected  to  the 
ATM155  Switch  should  have  155  Mbps  connections.  The  other  servers  should  have  25.6 
Mbps  connections.  SVCs  should  be  used  for  user  and  instructor  computers.  Figure  5.8 
illustrates  the  proposed  virtual  connectivity  for  the  ATM  LAN. 
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By  establishing  P  VCs  for  the  servers  and  switch-to-switch  connections,  and 
S  VCs  for  user  and  instructor  computers,  minimum  dedicated  virtual  connections  would  be 
used.  This  reduces  inefiBcient  use  of  bandwidth.  If  PVCs  were  used  for  the  user  and 
instructor  computers,  each  PVC  would  have  to  be  from  the  port  servicing  the  computer  to 
the  port  servicing  the  server.  If  the  computer  communicates  to  more  than  one  server,  then 
additional  PVCs  are  required.  As  one  can  see,  if  PVCs  were  used,  network  management 
would  be  drastically  increased.  Also,  more  time  is  required  to  establish  and  maintain 
PVCs. 


d.  Software  Requirement 

Table  5.2  provides  a  list  of  essential  software  to  ensure  the  proper 
functioning  of  the  SM  Lab  ATM  LAN.  Each  room  should  require  ATM  Svsdtching 
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software  to  operate  their  appropriate  segment  of  the  LAN.  The  software  should  have 
drivers  for  Novell  Netware  NOS,  WFW,  and  Windows  NT.  These  drivers  will  allow  the 
SM  Department  Lab  Network  to  operate  in  an  ATM  environment  as  it  migrates  fi’om  a  PC 
LAN  network  to  a  WFWAVindows  NT  network. 

The  stacked  switches  in  IN-224  and  IN-250  should  each  require  the 
Stacking  Bus  Module.  The  Module  should  allow  the  use  of  one  copy  of  ATM  Switching 
software  instead  of  the  actual  number  of  "stacked"  switches. 

The  ATM  Switching  software  drivers  for  the  ATM25  and  ATM155 
Switches  should  be  compatible  with  the  25.6  Mbps  NICs,  the  155  Mbps  Line  Interface 
Cards.  To  ensure  switch,  driver,  and  card  compatibility,  the  same  vendors  should  produce 
the  25.6  Mbps  NICs,  the  155  Mbps  Line  Interface  Cards,  switches,  and  ATM  LAN 
Bridge.  If  the  same  vendor  does  not  produce  these  items,  the  group  of  vendors  that 
manufactures  the  software  and  drivers  must  adhere  to  ATM  standards  to  ensure 
compatibility  and  interoperability. 


Item 

Qty 

Comments 

ATM  Switch  Software 

< 

Operating  System  for  the  Switches  must  have  drivers 
for  Netware,  Windows  for  Workgroup,  and  Windows 
NT.  The  Switch  Software  must  support  LAN 
Emulation.  This  requirement  is  also  applicable  to 
all  Drivers. 

Stacking  Bus  Module 

2 

For  Switches  in  IN-224  and  IN-250. 

25.6  Mbps  NIC  Drivers 

41 

For  Switches. 

155  Mbps  Line  Interface  Drivers 

7 

Switch-Switch  Coimectivity. 

ATM  LAN  Bridge  Software 

Must  be  compatible  with  the  switch  software. 

j 

LAN  Emulation  Software 

All  switches,  the  ATM  LAN  Bridge,  and  drivers 
must  have  LAN  Emulation  capability. 

Table  5.2  ATM  Software  Requirements 


The  LAN  Emulation  software  and  drivers  are  of  utmost  importance  to 
ensure  that  the  applications  on  the  current  SM  Department  Lab  Network  are  functional  in 
an  ATM  environment.  As  discussed  in  Chapter  IV,  Token-Ring  and  Ethernet  are  the 

primary  network  technologies  in  the  SM  Department  Lab  Network.  The  applications  are 
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designed  to  run  of  over  these  shared  medium  networks.  Standard  software  interfaces  or 
drivers  such  as  Novell's  ODI  or  Microsoft's  NDIS  interface  support  these  applications. 

ODI  and  NDIS  provide  network  transport  services  to  the  application 
software  that  operates  in  both  the  server  and  the  client  workstation,  and  these  services 
reflect  the  underlying  nature  of  the  LAN  technology.  Today's  Token-Ring  and  Ethernet 
LANs  provide  connectionless  "best  effort"  delivery  of  variable  length  packets  which  are 
addressed  to  a  specific  physical  interface(s).  These  LAN  technologies  also  support 
broadcast  and  multicast  packet  delivery,  whereby  a  packet  with  a  certain  address  will  be 
delivered  to  all,  or  a  subset  of,  the  workstations  on  the  network. 

The  higher  layer  of  the  communications  software  in  LAN  end  stations, 
including  the  client  "shell"  and  the  server  operating  system,  have  evolved  around  this 

functionality.  (Taylor,  Martin.  1995,  p.9) 

ATM  networks  operate  differently  than  today’s  traditional  networks.  ATM 
is  connection-oriented,  in  which  a  connection  is  established  before  any  information  is 
forwarded  to  the  destination.  Also,  data  is  fixed  length,  and  is  sent  to  the  appropriate 
destination(s)  by  the  use  of  virtual  channel  identifiers  instead  of  addresses  to  a  physical 
interface  card.  Last,  but  not  least,  ATM  does  not  provide  a  true  equivalent  of  broadcast 
and  multicast  services  offered  in  today's  LANs. 

LAN  Emulation  is  the  "solution"  to  the  problem  of  running  existing  LAN 
applications  over  an  ATM  network.  This  procedure  defines  a  "LAN  Emulation  Client" 
(LEC)  process  to  function  in  each  station,  which  adapts  the  connection-oriented  cell 
transport  service  provided  by  ATM  to  the  connectionless  packet  transport  service 
demanded  by  the  applications.  Figure  5.9  shows  how  LAN  applications  run  on  an  ATM 
network.  (Taylor,  Martin.  1995,  p.9) 
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LAN  Emulatioii  Client  Process 


Figure  5.9  LAN  Emulation  Client  Process 


As  depicted  in  the  above  figure,  the  LEC  process  handles  the  transmission 
and  receipt  of  LAN  packets  fi-om  the  ATM  network,  as  follows  (Taylor,  Martin.  1995, 
p.9-10): 
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♦  When  a  client  request  to  transmit  a  packet,  the  LEC  process  receives  packet's 
LAN  destination  address  and  determines  the  ATM  station  address.  If  no 
virtual  channel  connection  is  set  to  this  address,  the  LEC  request  that  the  ATM 
switch  establish  a  connection.  Once  the  connection  is  made,  the  LAN  packet  is 
segmented  into  ATM  cells  and  transmitted  over  the  connection. 

♦  If  a  client  or  server  request  to  transmit  a  broadcast  packet,  the  LEC  segments 
the  packet  into  cells  and  transmit  the  cells  to  the  Broadcast  and  Unknown 
Server  (BUS).  The  BUS  maintains  a  list  of  all  the  stations  on  the  ATM  LAN 
and  sends  the  cells  to  all  stations  on  the  list.  As  a  result,  the  appropriate 
stations  receive  the  broadcast  packet. 

♦  When  an  end  station  or  server  receives  a  stream  of  ATM  cells,  the  LEC 
re-assembles  the  cells,  re-creates  the  original  LAN  packet,  and  forwards  the 
packet  to  the  application. 

The  LEC  process  uses  one  of  the  standard  network  software  interfaces 
(ODI  or  NDIS)  to  communicate  with  the  end  station's  or  server's  application  software.  In 
actuality,  the  LEC  emulates  a  standard  ODI  or  NDIS  network  adapter  card  driver,  tricking 
the  end  station  software  into  believing  that  it  is  communicating  with  a  Token-Ring  or  an 
Ethernet  adapter.  Manufacturers  incorporate  the  LEC  process  into  the  driver  software 
that  shipped  with  the  ATM  adapter.  As  a  result,  it  is  a  simple  process  to  install  an  ATM 
adapter  complete  with  LAN  Emulation  in  a  server  or  client  software  environment. 
(Taylor,  Martin.  1995,  p.9) 

4.  LAN  Management 

Every  network,  regardless  of  size  or  type,  requires  network  management.  This 
will  be  particularly  true  for  the  proposed  ATM  LAN.  However,  to  properly  maintain  the 
ATM  LAN,  personnel,  personnel  training,  documentation,  and  maintenance  tool  are 
required.  The  subsequent  sub-subsections  address  these  requirements. 
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a. 


Personnel  and  Training  Requirement 


Two  or  more  people  may  be  required  to  maintain  the  proposed  integrated 
network.  These  people  will  be  responsible  for  the  upkeep  (adding,  deleting,  and 
modifying  virtual  and  physical  connections)  of  the  network.  They  will  also  perform 
upgrades  to  the  ATM  Switch  software  as  new  ATM  standards  are  released,  and  upgrade 
user,  instructor,  and  server  computers. 

The  current  LAN  administrator  is  very  familiar  with  existing  LAN 
technology.  However,  he  will  require  ATM  training,  and  possibly  training  in  the 
installation  of  fiber,  and  UTP,  or  STP  cable. 

b.  Documentation 

Documentation  is  of  utmost  importance  when  implementing  the  design  of 
the  ATM  network.  As  with  the  Token-Ring  and  Ethernet  networks,  documentation  of 
physical  connections  is  necessary.  However,  documentation  of  logical  links  is  very  critical 
for  the  integrated  network.  Though  all  physical  connections  may  be  up,  information  will 
not  reached  the  proper  destination  unless  the  correct  logical  connection  is  established.  If 
information  is  not  reaching  the  right  destination,  and  all  physical  connections  are 
established,  the  administrator's  next  step  is  to  ensure  that  the  switches  establish  the  proper 
logical  connection.  This  is  done  by  verifying  the  virtual  connection.  This  task  may  be 
very  difficult  to  perform  without  proper  physical  and  logical  documentation,  particularly  in 
a  large  network. 

c.  Maintenance  Tools 

Graphics  user  interface  (GUI)  maintenance  tools  will  greatly  assist  the 
LAN  administrator  in  maintaining  the  ATM  network.  However,  these  tools  can  be  very 
expensive.  A  small  ATM  network  may  not  require  a  GUI  maintenance  tool.  The  text 
editor  should  be  sufficient  for  the  small  network.  Because  the  SM  Lab  Integrated 
Network  will  consist  of  10  servers,  43  clients,  and  backbone  cormectivity,  a  GUI 
maintenance  tool  may  be  necessary.  This  tool  must  be  compatible  with  the  ATM 
switches. 
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Most  ATM  GUI  maintenance  tools  run  on  UNIX  platforms.  However, 
manufacturers  have  begun  producing  tools  that  can  run  on  a  Windows  NT  platform.  This 
is  a  great  stride  forward  for  ATM25  networks,  since  most  PC  networks  are  Windows-, 
Windows  NT-,  or  DOS-based.  The  Windows  NT  GUI  tool  would  greatly  assist  the  LAN 
administrator  in  maintaining  the  proposed  integrated  network. 

D.  CHAPTER  SUMMARY 

This  chapter  discussed  the  design  of  an  integrated  network  comprised  of  ATM, 
Token-Ring,  and  Ethernet  technologies.  However,  before  covering  the  design  of  the 
proposed  integrated  network,  the  chapter  covered  the  ATM  network  installed  for  the 
Supercomputing  1995  conference  in  San  Diego,  CA.  The  Supercomputing  1995 
conference  network  provided  me  a  better  understanding  of  how  an  ATM  network  is 
designed  and  implemented,  both  physically  and  logically.  As  a  result,  this  knowledge 
greatly  assisted  me  in  the  design  of  the  proposed  SM  Lab  Integrated  Network. 

Several  key  areas  were  covered  the  physical  and  logical  design  of  the 
recommended  network.  One  in  particular  was  the  use  of  one  vendor  for  the  integrated 
network.  To  ensure  compatibility  of  the  network,  one  vendor  should  manufacture  the 
switches,  an  ATM  LAN  Bridge,  LINF  cards,  and  NICs.  The  vendor  should  also  be  an 
active  member  of  the  ATM  Forum,  adhere  to  ATM  standards,  and  understand  ATM 
technology  and  its  evolution. 

Not  only  are  the  switches,  ATM  LAN  Bridge,  LINF  cards,  and  the  NICs  crucial  in 
the  physical  implementation  of  an  ATM  network,  but  the  cabling  plant  is  also  critical. 
Over  90%  of  the  SM  lab  network  cabling  plant  is  Type  1  (STP).  Though  ATM  runs  over 
Type  1  cable,  very  few  vendors  produce  cards  which  are  compatible  with  Type  1  cable. 
Mainly  STP,  UTP,  coax,  and  fiber  are  the  forms  on  which  cable  vendors  are  focusing. 

To  ensure  compatibility  and  not  be  left  with  few  vendors  to  procure  ATM 
hardware  fi'om,  UTP  and  fiber  are  the  recommended  choices  of  cable  for  the  Systems 
Management  Lab  Integrated  Network.  UTP  should  be  used  to  connect  the  user  and 
instructor  computers  and  the  servers  to  the  ATM  switches.  Multi-mode  fiber  should  be 
used  for  switch-switch,  ATM  LAN  Bridge-switch,  and  Pentium  Server-switch 
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connectivity.  The  fiber  is  recommended  for  these  connections  because  of  155  Mbps 
throughput  rate,  distance  (sAvitch-switch  connectivity),  and  the  possibility  of  noise 
interference. 

The  ATM  switches  recommended  for  the  lab  network  are  based  on  the  ATM25 
and  ATM155  technology.  This  technology  is  suitable  for  the  lab  network  because 
ATM25  was  designed  for  PC  desktop  networks.  The  ATM25  switches  should  comply 
with  ATM  standards,  particularly  LAN  emulation  and  UNI  3.0  standards.  LAN  emulation 
will  aUow  the  ATM  network  function  like  a  Token-Ring  or  Ethernet  network.  The  UNI 
3.0  standard  allows  the  use  of  SVCs  and  PVCs. 

The  ATM155  Switch  will  provide  high-speed  data  rates  between  the  switches,  and 
to  the  ATM  LAN  Bridge  and  Pentium  Servers.  The  ATM155  Switch  must  also  comply 
with  ATM  standards.. 

The  switch  software  must  not  only  address  these  standards,  but  it  must  also  use 
drivers  for  Novell  Netware,  WFW,  and  Windows  NT.  The  LINF  cards  and  NICs  for  the 
computers  must  also  use  compatible  drivers.  The  drivers  for  the  NICs  must  be  loaded  on 
each  computer  that  will  be  connected  to  the  ATM  switches 

If  all  the  hardware  (ATM  switches,  cabling,  LINF  cards,  NICs,  and  computers)  are 
properly  connected,  the  ATM  network  is  still  not  guaranteed  to  function  properly.  Both 
physical  and  logical  connectivity  must  be  established.  Logical  paths  (virtual  circuits)  must 
be  configured  after  physical  connectivity  has  been  established. 

Other  areas  of  concerns  are  personnel,  training,  documentation  and  maintenance. 
These  areas,  and  the  proper  physical  and  logical  connectivity  of  the  ATM  network  are  a 
must  to  efficiently  and  effectively  run  the  integrated  network. 
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VI.  MIGRATION  OF  SM  DEPARTMENT  LAB  LAN  TO  AN  ATM  LAN 


A.  PURPOSE  OF  CHAPTER 

The  purpose  of  this  chapter  is  to  discuss  a  migration  strategy  to  upgrade  the 
existing  SM  Department  Networks  Lab  from  Token-Ring  and  Ethernet  technologies  to  an 
integrated  network  encompassing  not  only  ATM  technology,  but  also  Token-Ring  and 
Ethernet  technologies.  Because  of  the  higher  throughput  rates  ATM  offers,  and  the 
greater  data  rates  users  will  expect  once  a  computer  is  upgraded  to  ATM,  this  chapter  will 
also  discuss  the  speed  limitations  of  existing  computers  when  they  are  connected  to  an 
ATM  switch. 

B.  INTEGRATED  LAN  MIGRATION  STRATEGY 

1.  Overview 

The  redesigned  SM  Department  Networks  Lab  LAN  discussed  in  the  previous 
chapter  should  not  be  implemented  in  one  phase.  A  one-phase  implementation  will 
produce  an  extended  period  of  downtime,  administrative  and  maintenance  training,  and  a 
tremendous  technology  risk  and  monetary  investment.  Instead,  the  migration  must  be 
done  in  phases  to  minimize  network  disruption,  maintenance  headaches,  technology  risks, 
and  costs.  Each  phase  should  leverage  as  much  of  the  existing  technology  (hardware  and 
software  configuration)  as  possible,  and  preserve  the  network  infrastructure  (Lindsay,  S., 
Rosenblum,  D.  and  Walleigh,  W.,  1995).  Other  factors  to  consider  when  migrating  to  a 
high-speed  network  include: 

♦  Existing  network  technologies; 

♦  Budget; 

♦  Where  network  bottlenecks  occur; 

♦  Type  of  cabling  available; 
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♦  Types  of  future  application  for  the  LAN; 

♦  Timeframe  considerations  (Carr,  J.,  1995,  p.  60). 

There  are  many  high-speed  network  technologies  available  in  the  marketplace 
which  may  be  used  to  upgrade  the  SM  Department  Networks  Lab  LAN.  These 
technologies  include  Fast  Ethernet  (lOObaseT),  lOOVG-AnyLAN,  FDDI,  and  ATM. 
However,  this  thesis  focuses  on  designing  an  ATM  LAN  that  would  possibly  be  an 
upgrade  to  the  current  LAN.  Therefore,  I  will  only  discuss  a  possible  migration  strategy 
using  ATM  technology. 

The  availability  of  funds  will  determine  how  quickly  a  high-speed  networking 
technology  will  be  phased  into  an  existing  network.  Even  if  a  vast  amount  of  funds  were 
available,  bottleneck  areas  should  be  considered  as  the  first  area  to  migrate  to  high-speed 
pipes.  This  approach  will  minimize  disruption  to  the  network,  the  procurement  of  new 
hardware  and  software,  and  improve  overall  performance  of  the  network. 

The  migration  strategy  should  also  use  as  much  of  the  existing  cabling  plant  as 
possible  to  minimize  cabling  cost  (material  and  installation).  The  other  two  factors,  types 
of  future  applications  and  timeframe  considerations,  will  also  determine  how  quickly  or 
slowly  one  would  implement  a  high-speed  network  technology.  In  the  case  of  the  SM 
Department  Networks  Lab  LAN,  these  two  factors  can  be  used  to  extend  the  migration  to 
phase  in  ATM  technology.  The  current  network  is  only  used  for  data  (text)  transfer  and 
not  to  transmit  or  receive  voice,  video,  and  images. 

To  devise  a  migration  strategy  for  the  SM  Department  Networks  Lab,  budgetary, 
bottleneck  areas,  and  cabling  plant  availability  and  compatibility  are  primary  concerns. 
These  concerns  are  used  in  creating  a  six  phase  approach  to  provide  ATM  services  to  the 
desktop.  These  phases  are  discussed  in  the  subsequent  subsections.  The  network 
administrator  can  combine  several  of  the  phases  if  additional  funds  are  available  or  time 
becomes  a  critical  factor. 
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2.  Phase  I:  Upgrade  Pentium  Servers  (IN-158)  to  ATM 
The  first  phase  of  the  SM  Department  ATM  LAN  evolution  is  the  conversion  of 
the  Pentium  Servers  (PN3  and  PN6)  in  IN-158  fi'om  16  Mbps  Token-Ring  to  155  Mbps 
ATM.  These  servers  are  converted  first  because  excess  traffic  on  a  Token-Ring  LAN 
creates  throughput  problems  which  causes  the  servers  to  respond  sluggishly  or 
inconsistently  to  application  requests.  This  may  cause  sessions  to  die  while  waiting  for 
acknowledgments  from  a  far  end  of  a  connection.  As  a  result,  user  productivity  degrades. 

The  converted  servers  are  connected  to  a  155  Mbps  high-speed  ATM  Switch. 
This  switch  will  be  connected  to  an  ATM  LAN  Bridge.  The  primary  purpose  of  the 
bridge  is  to  provide  connectivity  to  the  ATM  Switch  and  the  existing  Token-Ring 
network.  Therefore,  no  changes  are  required  to  the  existing  Token-Ring  infrastructure, 
and  users  will  have  the  ability  to  access  the  DOS-  and  Windows-based  applications  on  the 
Pentium  Servers  using  ATM  technology.  Also,  backbone  connectivity  remains  intact. 
Figure  6.1  illustrates  the  Phase  I  implementation. 


SM  Department  ATM  LAN  Evolution,  Phase  I 


(SATM) 


Server  PhO 


155  Mbps  ATM  Switch 


Pentium  Servers  Detached  from 
Tc4cen-Ring  Network  and 
Configured  for  AIM 


Can:q)us  Bacld^one 
Connection 


Figure  6. 1  SM  Department  ATM  LAN  Evolution,  Phase  I 
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3.  Phase  11:  Integrate  the  Ethernet  LAN  (4EN)  into  the  Network 

As  shown  in  Figure  6.2,  next  page,  the  only  difference  between  Phase  I  and  Phase 
n  is  the  connection  of  Segment  4EN  (Ethernet)  to  the  ATM  LAN  Bridge.  This  addition 
will  require  a  coaxial  cable  run  from  IN-224  to  IN-158  to  physically  connect  the  Repeater 
to  the  bridge.  Both  the  repeater  and  the  bridge  must  be  compatible  in  order  for  the 
connect  to  function  properly. 

While  running  the  coaxial  cable  from  IN-224  to  IN- 158,  the  cable  installer  may 
also  want  to  run  a  multi-mode  fiber  cable.  The  multi-mode  fiber  will  be  required  to 
connect  an  ATM25  switch  to  the  ATM155  switch  in  IN-158  during  Phase  IV. 

One  key  advantage  about  this  phase  is  that  Ethernet  users  will  have  the  ability  to 
access  applications  on  the  various  servers  on  the  network.  Also,  in  the  WFW 
environment,  the  4EN  users  will  have  peer-to-peer,  and  peer-to-server  capabilities.  These 
new  capabilities  are  much  more  than  the  current  functionality  of  the  4EN  users.  The  4EN 
users  can  only  perform  TCP/IP  functions,  via  the  Ethernet  campus  backbone  connection, 
with  the  Token-Ring  users. 

Regarding  the  Ethernet  campus  backbone  connection,  this  connection  will  remain 
in  place  during  this  phase. 
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4.  Phase  ni:  Disable  4£N  Backbone  Connection 

In  Phase  HI,  the  Ethernet  campus  backbone  connection  is  disabled.  However,  the 
AUI  cable  run  will  remain  in  place.  By  leaving  the  cable  in  place,  this  links  can  be  used  as 
a  secondary  or  backup  backbone  connection  should  the  Token-Ring  backbone  connection 
becomes  inactive. 

The  Ethernet  users  will  still  have  access  to  the  campus  backbone  via  the  ATM 
LAN  Bridge  and  Segment  4TR  (Token-Ring).  With  this  access,  the  Ethernet  users  keep 
their  internet  capabilities. 

Figure  6.3  shows  the  disabling  of  the  Ethernet  campus  backbone  connection. 
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5.  Phase  IV;  Upgrade  Four  IN-224  Computers  to  ATM 

Phase  rv  involves  migrating  computers  from  Token-Ring  to  ATM.  This  stage  will 
require  the  installation  of  multi-mode  fiber  cable  from  ESr-224  to  IN- 158  to  connect  a  25.6 
Mbps  ATM  Switch  to  the  high-speed  155  Mbps  ATM  Switch.  The  connection  will 
require  two  155  Mbps  Line  Interface  Cards,  one  for  each  switch,  and  the  appropriate 
connectors. 

After  connectivity  between  the  switches  have  been  established,  and  the  switches 
have  been  configured,  computers  can  be  connected  to  the  ATM25  Switch.  ATM  NICs, 
and  STP  or  UTP  cable  are  necessary  to  make  these  connections.  The  ATM25  Switch, 
NICs,  and  cable  must  be  compatible  to  obtain  a  connection. 

As  shown  in  Figure  6.4,  the  4 ATM  segment  co-exists  with  all  three  Token-Ring 
segments  and  4EN.  The  users  in  4ATM  will  be  able  to  communicate  with  the  servers  and 
other  users  of  the  integrated  network. 
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Figure  6.4  SM  Department  ATM  LAN  Evolution,  Phase  IV 


6.  Phase  V:  Upgrade  Four  IN-250  Computers  to  ATM 

During  Phase  V,  several  computers  in  IN-250  will  be  converted  from  Token-Ring 
to  ATM.  This  stage  will  require  the  installation  of  multi-mode  fiber  cable  from  IN-250  to 
IN-158  to  connect  a  25.6  Mbps  ATM  Switch  to  the  high-speed  155  Mbps  ATM  Switch. 
Like  the  IN-224  and  IN-250  ATM  link,  this  connection  will  require  two  155  Mbps  Line 
Interface  Cards,  one  for  each  switch,  and  the  appropriate  connectors.  The  same 
procedures  done  to  connect  the  computers  in  IN-224  to  that  ATM25  Switch  is  required  to 
connect  the  computers  in  lN-250  to  an  ATM25  Switch. 

Figure  6.5  illustrates  the  progression  in  the  integrated  network,  with  the  addition 
of  the  ATM25  Switch  in  IN-250. 
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7.  Phase  VI;  Convert  AU  IN-250  Computers  and  13  IN-224  Computers 

Phase  VI  is  the  final  stage  in  evolving  the  SM  Department  Lab  LAN  fi-om 
Token-Ring  and  Ethernet  technologies  to  an  integrated  network  comprised  of  ATM, 
Token-Ring,  and  Ethernet  technologies.  This  phase  entails  upgrading  all  but  three 
Token-Ring  configured  computers  in  IN-224  to  ATM.  All  remaining  Token-Ring 
configured  computers  in  IN-250  will  be  upgraded  to  ATM.  An  additional  switch  is 
necessary  for  both  rooms  to  accommodate  the  newly  converted  computers.  These 
switches  will  be  stacked  on  top  of  the  original  ATM25  Switches  in  each  room  using  the 
Stacking  Bus  Option.  The  newly  reconfigured  stacked  switches  in  IN-224  and  IN-250 
increase  the  capacity  of  each  room  to  support  24  computers. 
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Only  17  computers  in  IN-224  will  be  upgraded  to  ATM,  leaving  three  Token-Ring 
configured  computers  on  Segment  4TR.  Twenty-four  of  the  25  computers  in  IN-250  will 
be  converted  to  ATM.  The  remaining  computer  in  IN-250  can  either  remain  on  Segment 
OTR.  However,  since  the  Pentium  Servers  in  IN-158  will  become  the  application  servers 
for  IN-250,  fewer  servers  will  be  required  in  IN-250.  As  a  result,  all  user  computers, 
including  the  instructor  computer,  can  be  converted  to  ATM. 

Even  though  the  stacked  switches  in  IN-250  is  at  maximum  capacity,  a  third 
switch  can  easily  be  added  to  the  stack  should  the  number  of  ATM  computers  becomes 
25  or  greater. 

Figure  6.6,  on  the  next  page,  shows  the  implementation  of  Phase  VI.  This  final 
implementation  consists  of  the  following: 

♦  Segment  OATM  -  Stacked  ATM25  switches  and  24  ATM  configured 
computers; 

♦  Segment  4ATM  -  Stacked  ATM25  switches  and  17  ATM  configured 
computers; 

♦  Segment  8 ATM  -  an  ATM155  Switch,  ATM  LAN  Bridge,  and  two  Pentium 
Servers.  Additional  high  powered  servers  can  be  added  the  ATM155  Switch; 

♦  Segment  4TR  -  a  MAU,  three  computers,  backbone  connection,  and  an  ATM 
LAN  Bridge  connection; 

♦  Segment  8TR  -  a  MAU,  486  Server,  five  clients,  and  an  ATM  LAN  Bridge 
connection; 

♦  Segment  4EN  -  Ethernet  Repeater,  five  computers,  a  disabled  backbone 
connection,  and  an  ATM  LAN  Bridge  connection. 
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C.  THROUGHPUT  LIMITATIONS 

Though  ATM  is  a  "relative"  new  networking  technology,  it  is  growing  in 
popularity  and  is  being  adapted  by  many  companies  and  institutions.  These  organizations 
have  realized  the  benefits  ATM  offers,  such  as  a  vast  room  for  growth  in  bandwidth. 
Numerous  other  benefits  are  discussed  in  Chapter  n. 

Even  with  the  on-going  evolution  of  ATM  standards,  products  (ATM  switches, 
line  interface  cards,  NICs,  etc.)  are  being  manufactured.  Most  of  the  products  are  in 
compliance  with  the  existing  ATM  standards.  As  a  result,  these  products  can  be  procured 
and  configured  to  form  a  fully  functioning  ATM  network.  The  network  can  serve  users 
within  a  single  building  or  campus,  or  even  users  thousands  of  miles  apart.  The  network 
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can  support  speeds  ranging  from  25.6  Mbps  to  2.4  Gbps.  The  high  throughput  would 
support  ATM  backbones. 

Though  ATM  supports  these  high  rates  of  throughput,  an  Information  Technology 
Manager  must  ask  himself  the  following  technical  questions: 

♦  Can  the  ATM  network  support  all  popular  PC  buses  (ISA,  EISA,  PCI, 
NuBus),  device  drivers  for  my  operating  system  (WFW,  Windows  NT,  Novell 
Netware)? 

♦  Does  the  ATM  network  emulate  LANs  for  both  ATM  adapters  and 
internetworking  devices. 

♦  Can  my  existing  PCs  or  workstations  handle  ATM  speeds? 

Chapters  n  and  V  address  the  first  two  questions.  Therefore,  the  next  paragraphs 
will  focus  on  throughput. 

Communications  Week  tested  four  ATM  switches  during  the  summer  of  1995. 
The  tests  focused  on  the  switches'  viability  as  desktop  network  interfaces.  The  switches 
included  Fore  Systems  Inc.'s  ForeRunner  ASX-200BX,  Newbridge  Networks  Inc.'s  Vivid 
ATM  Workgroup  Switch,  3Com  Corp's  Cellplex  7000,  and  UB  Networks  Inc.'s 
GeoSwitch/155.  Though  these  switches  provided  155  Mbps  bandwidth,  the  throughput 
tests  performed  by  Communications  Week  illustrate  the  bottleneck  of  the  network  when 
using  ATM  technology.  (Mier,  E.  E.,  Smithers,  R.  J.,  Jr.,  1995,  p.  129) 

Communications  Week  implemented  single-ATM-switch  LANs,  connected 
Pentium-based  PC  workstations  to  the  switches  using  155  Mbps  multi-mode  fiber 
adapters,  and  transferred  real  data  traffic  over  TCP/IP.  Each  Pentium  computer  had  64 
Mbytes  of  RAM,  and  a  clock  speed  of  90  MHz.  Half  of  the  PCs  ran  Window  NT  Server 
3.51,  and  the  remaining  half  ran  Windows  NT  Workstation  3.51. 

Communications  Week  tested  the  throughput  speeds  of  the  155  Mbps 
(bi-directional)  ATM  network  and  an  Ethernet  running  at  10  Mbps.  The  technicians 
determined  that  the  effective  user  data  throughput  over  Ethernet,  within  a  Windows  NT 
Workstation  and  a  Windows  NT  Server  as  the  only  active  nodes,  was  4  Mbps.  The  file 
size  was  323  megabytes. 
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The  same  file  was  transferred  over  the  ATM  PVC.  The  data  transferred  at  an 
effective  rate  of  13  Mbps.  As  one  can  see,  this  is  nowhere  near  155  Mbps.  Disk  I/O 
limited  the  transfer  rate  to  13  Mbps. 

To  perform  the  file  transfer  without  conducting  disk  VO  functions,  the  technicians 
performed  a  cache  memory-to-cache  memory  transfer  of  a  50  megabyte  file  (the  cache 
could  not  hold  the  323  megab5te  fiile).  The  effective  transfer  of  the  50  megabyte  file  was 
30  Mbps,  also  much  smaller  than  the  155  Mbps. 

These  throughput  rates  would  have  been  much  smaller  had  Communications  Week 
used  PCs  with  configurations  identical  to  the  PCs  in  the  SM  Department  computer  labs. 
Even  ATM  25  Mbps  switches  would  not  have  been  used  to  their  fullest  potential. 

Though  ATM  25  Mbps  switches  exceed  the  throughput  limitations  of  the  SM 
Department  Computer  Lab  LAN,  the  switches  would  allow  room  for  growth  and 
expansion  of  the  network.  As  newer  and  more  powerful  PCs  replace  the  existing  486 
PCs,  the  overall  throughput  speed  would  increase. 

D.  CHAPTER  SUMMARY 

This  chapter  discussed  the  proposed  implementation  strategy  to  incorporate  ATM 
technology  into  the  SM  Department  Lab  LAN.  The  strategy  pursued  a  course  which 
would  minimize  disruption,  downtime,  maintenance,  and  training.  In  the  six  phases, 
existing  hardware  and  software  are  used  to  the  fullest  extent  to  minimize  costs  and  risks. 

Because  of  the  redesigned  and  proposed  implementation  of  the  LAN,  Token-Ring, 
and  Ethernet  became  an  integral  part  of  the  ATM  LAN.  This  is  accomplished  through 
LAN  Emulation.  By  having  all  three  technologies  in  one  integrated  network,  the  students 
and  staff  will  gain  tremendous  experience  on  these  three  networking  technologies  and  how 
they  function  in  one  integrated  environment. 

One  key  advantage  of  the  integrated  network  is  that  users  will  retain  the  ability  to 
use  existing  applications  through  the  use  of  LAN  Emulation.  The  users  will  also  have 
greater  throughput  with  room  for  bandwidth  growth  as  applications  become  more 
powerful,  and  demand  additional  bandwidth. 
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Lastly,  the  ATM  segments  will  have  the  ability  to  support  data,  voice,  and  video 
transmission.  Though  the  SM  Department  Lab  users  currently  transmit  text,  future 
information  technology  procurements  may  include  more  powerful  servers  and  clients. 
These  computers  may  have  multi-media  capabilities  which  could  possibly  lead  to  the 
sharing  of  multi-media  resources  across  the  integrated  network. 
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vn.  CONCLUSION 


User  demand  for  additional  bandwidth  will  continue  to  increase.  In  many  cases, 
this  demand  will  grow  at  a  rate  faster  than  workstation  processing  power.  Since  the  SM 
Department  is  upgrading  its  computer  lab  network  to  WFW,  and  eventually  to  Windows 
NT,  more  powerful  applications  will  be  able  to  run  on  the  network.  These  applications 
will  require  faster  servers  and  clients,  and  additional  bandwidth.  Even  if  the  servers  and 
clients  are  replaced  with  much  faster  computers,  the  current  Token-Ring  and  Ethernet 
technologies  will  be  the  limiting  factor.  These  technologies  only  support  16  and  10  Mbps 
data  rates,  respectively,  and  are  not  capable  of  supporting  the  transmission  of  voice,  data, 
images,  and  video. 

ATM  provides  the  throughput  rates  (25.6,  155,  and  622  Mbps,  and  higher)  and  the 
capability  to  carry  voice,  data,  images,  and  video.  However,  this  technology  comes  with  a 
high  price  tag  and  risks.  One  would  not  want  to  replace  his  existing  shared-medium 
network  with  an  ATM  network  in  one  phase.  Instead,  ATM  technology  should  be  phased 
into  the  existing  network.  This  approach  reduces  risks,  and  maximizes  the  use  of  existing 
hardware  and  software.  The  migration  or  evolution  strategy  also  allows  time  for  the  ATM 
standards  to  mature  and  to  be  implemented  by  manufactures.  Cost  also  plays  a  critical 
role  in  the  evolution  strategy.  It  is  expected  that  ATM  prices  will  continue  to  decrease 
and  become  more  competitive  with  other  switching  technologies  such  as  SAvitch  Ethernet 
and  Switch  Token-Ring. 

Should  the  SM  Department  decide  to  upgrade  the  computer  lab  network  to  ATM, 
and  elect  to  use  the  proposed  migration  strategy  or  even  a  different  evolutionary  plan,  the 
manufacturers  that  provide  the  ATM  technology  will  play  a  crucial  role  during  and 
following  the  implementation.  The  manufacturers  should  be  a  member  of  the  ATM 
Forum,  adhere  to  ATM  standards,  and  understand  the  ATM  technology  and  its  evolution. 

If  the  manufacturers  meet  these  criteria,  the  ATM  products  will  be  interoperable 
and  compatible  with  other  vendors  ATM  products;  most  of  all,  the  products  will  function 
with  existing  LAN  applications.  The  ATM  equipment  will  also  have  a  longer  technology 


103 


life  cycle  (i.e.,  if  a  new  ATM  standard  is  released,  the  items  can  easily  adapt  the  new 
standard,  and  not  become  obsolescence). 
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APPENDIX  A.  ATM  FORUM  CURRENT  WORK  ITEMS 


ATM  FORUM  CURRENT  WORK  ITEMS  AS  OF  DECEMBER  1995 

The  ATM  Forum  Technical  Committee 

1  Technical  Working 
Group 

Principal  Work  Effort 

Status 

Approval 

Forecast 

Lan  Emulation  Chairman; 

LANE  V2.0  LUNI  Interface 

Work  In  Progress 

10/96 

Kieth  McCloghrie 

LANE  V2.0  Servcr-to-server  Interface 

Work  In  Progress 

10/96 

LANE  1.0  Addendium,  af-lane-0050,000 

Final  Ballot 

2/96 

LANE  Service  MIBs 

Straw  Ballot 

4/96 

MPOA  Chair: 

George  Swallow 

Specific  Development 

Work  In  Progress 

2/97 

TrajGBc  Mgmt  Chair; 

Natalie  Giroux 

TraflBc  Management  4.0 

Service  Architecture 

ABR  (Available  Bit  Rate) 

QoS  (Quality  of  Service) 

Straw  Ballot 

2/96 

Service  Aspects  and 

Native  ATM  Services;  Semantic  Description 

Final  Ballot 

2/96 

Application  Chain 

AudioA^isual  Multimedia  Services  VI. 0 

Final  Ballot 

2/96 

Dean  Skidmore 

FUNI  (Frame-based  User-to-Network  Interface) 

>^)proved 

10/95 

Circuit  Emulation 

Directory  Services 

/^jproved 

Work  In  Progress 

10/95 

Voice  &  Telephony  over  ATM 

Work  In  Progress 

10/96 

P-NNI  Chair; 

Mike  Goguen 

P-NNI  VLO  (Private  Network-to-Netwoik  Interface) 

MIB  contains  P-NNI  Signaling  and  Routing  Protocols 

Straw  Ballot 

4/96 

Physical  Layer  Chair: 

E-1 

Straw  Ballot 

4/96 

Rick  Townsend 

25.6  Mbps 

Approved 

10/95 

155  UTP-3 

Final  Ballot 

2/96 

622  Optical 

ATM  Inverse  Mux 

Final  Ballot 

Work  In  Progress 

2/96 

Utopia  Level  2 

Wire  (PMD  to  TC  layers) 

Straw  Ballot 

Work  In  Progress 

2/96 

E3UNI 

^proved 

10/95 

DS3  Physical  Layer  Interface  Spec 

Final  Ballot 

2/96 

120  Ohm  Addendum  to  ATM  PMD 

Straw  Ballot 

4/96 

Interface  Spec  for  155  Mbps  over  TP,  af-phy-0053.000 

Straw  Ballot 

4/96 

Signaling  Chair: 

Tom  Helstem 

UNI  Signaling  4,0 

Straw  Ballot 

6/96 

B-ICI  Chair; 

Richard  Breauh 

B-ICI  2.0 

Straw  Ballot 

4/96 

Network  Management 

M4  Public  Network  view 

Final  Ballot 

2/96 

Chair:  Roger  Kosak 

M4  SNMP  MIB  Network  Element 

Work  In  Progress 

4/96 

M3  (CNM)  Update 

Work  In  Progress 

6/96 

M4  Public  Network  view  SNMP  &  CMIP  MIB 

Work  In  Progress 

6/96 

Power  Management 

Work  In  Progress 

9/96 

M5  Carrier  Interface 

Work  In  Progress 

9/96 
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Testing  Chair: 

PICS  for  AAL  (ITU  spec) 

Final  Ballot 

12/95 

Gregan  Crawford 

PICS  for  Signaling  (UNI  V3.0) 

Tabled 

PICS  for  Signaling  (UNI  V3.1) 

Work  In  Progress 

Conformance  Abstract  Test  Suite  for  ATM  layer  (End  Sys) 

Approved 

10/95 

Conformance  Abstract  Test  Suite  for  the  AAJL5  Sub-Layer 

Final  Ballot 

2/96 

Conformance  Abstract  Test  Suite  for  SSCOP  Sub-layer 
Conformance  Abstract  Test  Suite  for  Signaling  (UNI  3.1)  - 
User  Side 

Conformance  Abstract  Test  Suiite  for  UNI  3. 1  at  the  ATM 

Work  In  Progress 
Work  In  Progress 

j^jproved 

12/95 

Layer  for  Intermediate  Systems 

PICS  for  UTP-3  (52  Mbps)  16  CAP  Physical  Layer 

Final  Ballot 

2/96 

PICS  for  the  25.6  Mbps  over  UTP-3  Physical  Layer 

Final  Ballot 

2/96 

Conformance  Abstract  Test  Suite  for  the  UNI  3.1  ATM  Layer 

Straw  Ballot 

4/96 

of  End  System 

RBB  (Residential 
Broadband) 

Chair:  Stanley  Ool 

;  Requirements  for  Specification:  RBB  Specification 

Work  In  Progress 

12/96 

Security  Chair: 

Mohammed  Peyravian 

Security  1.0 

Work  In  Progress 

2/97 

1  Work  in  Progress:  All  work  up  to  release  of  working  documment  for  Straw  Ballot 

Straw  Ballot:  Specification  released  for  test  vote  with  comments  (some  may  require  two  rounds). 

Final  Ballot:  Final  specification  presented  for  vote  or  membership. 

Approval:  i^provalvote  received. 
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APPENDIX  B.  THE  ATM  REPORT  GUIDE  TO  LANE  PRODUCTS 


ATM  Switches,  Hubs,  &  Routers 

Company 

Product 

LAN  Emulation 

IETF  IP  over  ATM 

Agile 

ATMizer  125  ATM  Switch 

ATMFLANE  1.0 

RFC  1483 

Alantec 

PowerCell  350  module  for 
PowerHub  3000/5000  & 
PowerHub3160 

Power  Cell  700 

PowerCell  600 

FORE  LANE 

ATMFLANE  1.0 -IQ  96 

ATMFLANE  1.0 -IQ  96 
ATMFLANE  1.0 -IQ  96 

RFC  1577 -IQ  96 

RFC  1577 -IQ  96 

ATM  Inc. 

Virata  Switch 

ATMF  LANE  1.0 

Bay  Networks 

EtheiCell  Switch 

LattisCell 

System  5000AH  ATM  Module 
Backbone  Node  Routers 
(BLN&BCN) 

ATMFLANE  Client 
ATMFLANE  LO 

AMTF  LANE  1.0 

AMTF  LANE  1.0 

RFC  1483 

RFC  1483  &  1577 

Cisco 

Cisco  7000  with  AIP 

Cisco  4500/4700  with  NPN 
Cisco  lOS  for  ATM  Software 
Cisco  Catalyst  5000 

ATMF  LANE  1.0 

ATMF  LANE  1.0 

AMTF  LANE  1.0 

AMTF  LANE  Clinet 

RFC  1483  &  1577 

RFC  1483  &  1577 

RFC  1483  &  1577 

3Com 

CELLplex  7000  &  7200  ATM 
Module 

LinkSwitch  2700 

AMTF  LANE  1.0 

AMTF  LANE  CUent  w/SVCs 

CrossComm 

XLT-F  Edge  Router 

AES  ATM/Ethemet  Edge 

Switch 

ATMF  LANE  Client 

AMTF  LANE  1.0  Client 

IQ  96 

RFC  1483  &  1577 

RFC  1483 

Digital 

GigaSwitch  ATM 

DECNIS  ATMcontroller631 

AMTF  LANE  1.0 

RFC  1483  &  1577 

RFC  1483  &  1577 

First  Virtual 

Media  Switch 

AMTF  LANE  1.0 

RFC  1483  &  1577 

FORE 

ASX-1000  &  ASX-200  WG* 

&  ASX-200BX 

FORE  LANE  0.4 
ATMFLANE  1.0 -IQ  96* 

RFC  1483  &  1577 

IBM 

8281  ATM  LAN/Bridge 

8285  ATM  Workgroup  Switch 

IBM  LANE 

AMTF  1.0 -IQ  96 

RFC  1483  &  1577 

RFC  1483  &  1577 

Madge 

Collage  250 -IQ  96 

Collage  280 

ATMFLANE  1.0 

Newbridge  VIVID 

Vivid  Switches  &  Bridges 

Newbridge  MPOA 

RFC  1483 

NSC 

ERS 

ATMFLANE  1.0 

ODS 

Warrior  Switch 

FORE  Module 

AnyCell  ATM25 

ATMFLANE  1.0 

FORE  LANE 

IBM  LANE 

RFC  1483  &  1577 

UB  Networks 

GeoSwitch/155 

ATMF  LANE;  Client  & 
Server  services 

Whitaker  (Hughes  LAN) 

Enterprise  Hub 

Ethernet  Switch  with  ATM 

ATMFLANE  1.0 

ATMF  LANE  1.0 

Whitetree 

Whitetree  WS3000 

ATMF  LANE  1.0 

Xyplex 

520  ATM  Edge  Router  Module 

ATMF  LANE  1-0-  IQ  96 

RFC  1483, 1577 -IQ  96 
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Xylan 


OmniSwitch  with  OmniCell 
ATM  Matrix -Q1  96 
7000  Series 


ATMFLANE1.0.1Q96 


RFC  1483  &  1577 


ATMNICs 


Company 


Adaptac 


ATM  Inc. 


3Com 


Efficient  Networics 

First  Virtual 


FORE 


Interphase 


Madge 


Packet  switch  Tech. 


SysKonnect 


Product 

LAN  Emulation 

IETF  IP  over  ATM 

ATM  155  for  SBus  &  PCI  Bus 
ATM25  for  PCI,  SBus,  Micro 
Channel 

ATMF  LEG 

RFC  1577 

Virata  Link 

ATMF  LANE  1.0  Client 

ATMLink  155  Mbps  for  SBus 

AMTFLANE 

RFC  1577 

ATMworks  750  &  350  for 
Turbo  channel  &  PCI 

AMTFLANE  Client 

RFC  1577 

155  Mbps  SBus,  PCI,  EISA 

100  Mbps  SBus,  EISA 

25  Mbps  PCI -IQ  96 

ATMF  LANE  1.0 

RFC  1577/1755 

Media  Adapter  25  Mbps 

AMTFLANE  1.0  Client 

ATM  NICs  for  Sbus,  EISA 
GIO,  MCA  VME,  NuBus, 

PCI,  MAC-PCI 

FORE  LANE 

ATMF  LANE  1.0 -IQ  96 

RFC  1483/1577  -  IQ  96 

TurtoWays  25/100/155  Mbps 
NICs  for  ISA,  MCA 

IBM  LANE 

AMTFl.O-lQ  96 

155  Mbps  PCI,  Sbus,  EISA 
VME,  GIO,  PMC 

100  Mbps  SBus,  EISA  VME 

ATMF  LANE 

RFC  1577  (SVCs) 

RFC  1483  (PVCs) 

Collage  25/155  Mbps  NICs 
for  PCI 

ATMF  LANE  1.0 

IAX-210  155  Mbps  PCI  NIC 

RFC  1577 

SK-NET  155  Mbps  NICs 
forSBus,  EISA  &  PCI 

RFC  1577 

155  Mbps  NICs  for  PCI, 

SBus,  EISA  &  GIO 

LANE  Client,  Server,  &  BUS 

RFC  1483  &  1577 

*  -  Fore  ASX-200WG  LANE  server  software  supports  diretly  attached  clients  only. 
FORE  will  offer  ATMF  LANE  1.0  compliance  on  all  products  by  3/96. 

MPOA  -  Multiprotocol  over  ATM 

RFC  1483  -  defines  the  encapsulation  of  IP  datagrams  directly  in  AAL5. 

RFC  1577  -  is  intended  to  make  IP  run  over  ATM  as  efiBciently  as  possible. 
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